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PREFACE 


This  research  effort  describes  the  continued  development  of  an 
Improved  Universal  Network  Interface  Device  (UNID  II).  The  UNID  II's 
architecture  was  based  on  a  preliminary  design  project  at  the  Air  Force 
Institute  of  Technology.  The  UNID  II  contains  two  hardware  modules:  a 
local  aodula  for  the  network  layer  software  and  a  network  module  for  the 
data  link  layer  software  and  physical  layer  interface.  Each  module  is 
an  independent  single  board  computer  (SBC)  residing  on  an  Intel  multibus 
chassis,  complete  with  its  own  memory  (EPROM  and  RAM),  serial  link 
Interfaces,  and  multibus  interface.  The  local  module  is  an  iSBC  544  and 
the  network  module  is  an  iSBC  38/45.  This  report  documents  the  detailed 
hardware  and  software  design,  test,  and  integration  of  this  system. 

I  especially  thank  my  thesis  advisor,  Dr.  Gary  Lament,  for  his 
^  •  persistence  and  perseverance  In  nudging  me  through  this  challenging  and 

successful  endeavor.  My  thanks  as  well  to  Major  Walter  ward  and  Major 
ken  noth  Castor  for  their  valuable  comments,  .suggestions,  and 
encouragement  during  the  course  of  this  investigation.  I  greatly 
appreciate  the  assistance  from  Mr.  Orville  Wright,  Mr.  Chaclle  Powers, 
Capt  Lee  Baker,  and  Mr.  Robert  Durham  Eor  their  technical  and  supply 
support.  To  Capt  Ren  Cole  goes  special  appreciation  for  the  stimulating 
and  challenging  theoretical,  technical  and  recreational  conversations  In 
the  'INI')  developmental  phases  during  the  dead  of  the  night.  Last,  but 
certainly  not  least,  to  my  two  sons,  Marek  and  Derrick:  We  will  soon 
have  the  time  tor  the  fishing,  skiing,  hiking  and  hunting  that  we  have 
foregone  these  last  13  months;  thank  you  for  your  patience.  To  .ny  wife 
ieglna  gees  special  appreciation  for  her  patience  and  anderstandlng. 
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Abs  trac t 


This  rssaarch  effort  describes  the  continued  development  of  an 
inproved  Universal  Network.  Interface  Device  (UNID  II).  The  UNID  It's 
architecture  was  based  on  a  preliminary  design  project  at  the  Air  Force 
Institute  of  Technology.  The  UNID  It  contains  two  main  hardware 
nodules;  a  local  module  for  the  network  layer  software  and  a  network 
nodule  for  the  data  link  layer  software  and  physical  layer  interface. 
Each  nodule  is  an  independent  single  board  computer  (.SBC)  residing  on  an 
Intel  multibus  chassis,  complete  with  its  own  memory  (EPROM  and  RAM), 
serial  link  interfaces,  and  multibus  interface.  The  local  module  Is  an 
Intel  1S3C  544  and  the  network  module  Is  an  Intel  ISBC  33/45.  The 
network  layer  software  supports  the  CCITT  <.25,  datagram  option, 
protocol  and  the  data  link  layer  software  supports  the  CCITT  .<.25  LAP B 
(HOLC)  protocol.  This  report  documents  the  detailed  hardware  and 
software  design,  Integration,  validation  and  test  of  this  system. 


CONTINUED  DEVELOPMENT  AND  IMPLEMEN TATION 
OF  THE 

UNIVERSAL  NETWORK  INTERFACE  DEVICE  (UNIO)  II 

IN  THE 

DIC  UAL  ENGINEERING  LABORATORY  NETWORK  (DELNET) 

I .  Introduction  and  Background 

Introduction 

This  thesis  describes  the  development  and  Implementation  of  the 
Universal  Network  Interface  Device  (UNID)  II.  Chapter  One  provides  an 
Introduction  to  the  UNID  and  the  Digital  Engineering  Laboratory  Netwock 
(DELNET).  Chapter  Two  elaborates  on  the  requirements  and  standards  used 
In  the  UNID  and  DELNET.  Chapter  Three  explains  the  hardware 
architecture  and  Chapter  Four  elaborates  upon  the  supporting  software 
design.  Chapter  Five  describes  the  testing  philosophy,  design  and 
results  while  Chapter  Six  concludes  the  thesis  with  a  summary  and 
recommendations  for  future  work. 

Chapter  One  begins  with  the  background  of  tbe  Digital  Engineering 
Laboratory  Network  (DELNET)  and  the  Universal  Network  Interface  Device 
(UNID)  I.  It  then  covers  the  current  status  of  the  UNID  11,  problem 
.statement,  scope,  assumptions,  standards,  approach,  equipment,  -.nu  other 
support  required  to  develop  atid  implement  a  working  UNID  II. 

Background 

In  1977,  a  report  from  the  1342nd  Electronics  Engineering  Group 
(AFCC)  stated  that  a  Local  area  network  (LAN)  wouLd  be  an  ideal 
candidate  to  connect  the  myrLad  of  electronic  dat3  devices  resident  on  a 
typical  Air  Force  Base  (1).  The  authors  of  the  report  saw  the  need  for 


some  method  of  connecting  these  equipments  In  such  a  wa y  so  that  user 
data  processing  and  telecommunications  needs  could  be  efficiently  and 
effectively  satisfied.  The  report  summarized  that  a  multi-ring  network 
concept  would  be  a  primary  candidate  for  -a  typical  base  level 
teleprocessing  and  narrative  message  network  of  the  Late  1930's.  A  key 
to  the  multi-ring  concept  was  the  development  of  five  different 
functional  devices  to  handle  the  requirements  of  interfacing  the  diverse 
user  equipment  to  the  multiple  ring  structure.  This  basic  idea  was 
expanded  and  tasked  to  Rome  Air  Development  Center  (RADC)  for 
incorporation  into  a  post  doctoral  study  program  (75).  An  initial 


concept  of  the  multi-ring,  base  level  network  is  shown  in  Figure  l-l. 
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Figure  l-l .  Initial  Concept  of  a  Multi-Ring  Base  Level  Network  (75) 


Further  investigation  of  the  system  requirements  and  functional 
definitions  revealed  that  the  five  different  devices  could  be 
incorporated  into  one  piece  of  hardware.  Since  the  single  device  must 
Interface  many  different  user  equipments  with  the  multiple  ring 
structure,  It  was  given  the  name  Universal  Network  Interface  Device,  or 


!NID.  for  short. 
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It  wis  at  this  point  that  the  Air  Force  Institute  of  Technology 
( A F I T )  became  Involved.  An  overall  plan  was  developed  for  the 
architectural,  hardware  and  software  designs  of  both  the  DELNET  and  the 
UNID.  The  plan  also  Included  the  use  of  the  DELNET  and  UNID  for 
educational  purposes  In  computer  network  courses  and  research. 
Master's  level  thesis  efforts  began  In  1978  with  Sluzevlch  who  outlined 
the  initial  conceptual  hardware  and  software  designs  for  the  'JNID. 
SluzevLch  separated  the  design  of  the  UNID  into  four  tasks  (84): 

1.  Define  the  functional  requirements  of  the  UNID. 

2.  Translate  functional  requirements  into  system  design. 

3.  Design  the  UNIQ's  hardware. 

4.  Design  the  UNID's  software. 

The  ’JNID  began  its  evolution  in  a  modular  design  which  would  allow 
the  required  degree  of  universality.  The  design  consisted  of  three 
logical  parts.  The  first  part  interfaced  the  UNID  with  the  host 
equipment.  The  second  Interfaced  the  UNID  with  the  multiple  rLng  LAN. 
The  third  part  was  a  processor  to  provide  the  control  and  processing 
capabilities  for  the  first  and  second  pieces.  In  1979,  Brown  (7) 
upgraded  the  basic  design  by  expanding  the  processor  into  two 
processors,  one  for  the  local  host  equipment  and  the  second  for  the  ring 
LAN.  A  shared  block  of  memory  was  also  included  in  the  design  to  allow 
the  two  processors  to  move  data  from  the  local  to  network  hardware  and 
vice  versa.  In  1980,  Baker  (4)  addressed  the  need  for  further  software 
development  and  testing  of  both  the  hardware  and  software  required  to 
obtain  an  operational  device.  Me  also  Improved  existing  hardware  and 
software  development  tools  to  accomplish  the  UNID  hardware  and  software 
testing.  In  1981,  Papp  (74)  ievelopad  the  operational  hardware  for  the 


UNID.  ULs  work  also  lncLuiied  complete  documentation  and  tasting.  Caomo 
(11),  In  1982,  Improved  the  hardware  design  by  changing  the  processor 
memory  from  dynamic  to  static,  Including  four  ports  for  the  local  host 
processors,  and  Improved  the  Internal  wiring  to  minimize  noise  and 
spurious  Interference.  Spear  (86),  In  1983,  began  a  through  redesign 
and  i mplamantatlon  of  the  UNID  1  hardware  to  eliminate  many  timing  and 
other  wiring  problems  that  had  heretofore  existed. 

At  the  same  time  Sluzevich  began  the  UNID  development,  Ravenscroft 
began  work  on  the  conceptual  design  of  a  local  area  network  for  the 
Digital  Engineering  Laboratory  (DEL),  later  called  the  DELNET  (73). 
Hobart  (33),  in  early  1981,  began  the  conceptual  development  of  the 
software  which  would  eventually  be  needed  for  the  DEL.  He  used 
structured  analysis  and  design  techniques  (SADTs)  to  develop  the  initial 
data  flow  diagrams  (DFD)  for  the  network.  In  1981,  Gelst  (29)  began  the 
protocol  development  for  the  UNID.  He  used  the  International  Standards 
Organization  (ISO)  Open  Systems  Interconnection  (OSI)  (12)  model  as  the 
basic  framework  for  software  design  and  development  In  an  effort  to 
provide  a  standardized  set  of  network  protocols,  lie  further  refined  the 
Initial  dat3  flow  requirements  and  documentation.  In  1932,  Hazelton  (32) 
Improved  the  first  three  protocol  layer  designs.  He  developed  the  basic 
software  for  the  Implementation  of  the  Consultive  Committee  for 
International  Telephone  ind  Telegraph  (CCITT)  Link  Access  Protocol  (LAP) 
at  the  data  ILnk  Layer  and  the  basic  structure  of  the  CCITT  K.25 
protocol  for  the  network  layer. 

In  1983,  Phlster  (75)  Improved  the  data  link  layer  software, 
developed  the  Initial  network  layer  software  for  datagram  use,  and 
developed  the  Initial  start  of  the  transport  layer  protocol  using  the 
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CCITT  X.121  and  rransmlsslon  Control  Protocol/ Internet  Protocol 
(TCP/ IP).  The  DELNEf  standards  were  also  established  during  this  effort 
and  are  described  In  (75:Appen  C).  The  requirements  and  documentation 
are  discussed  in  detail  In  Hobart  (33),  Gelst  (29),  Hazelton  (32),  and 
Phlster  (75:Appen  G)  and  reviewed  for  completeness  in  Chapter  Two  of 
this  thesis.  With  the  application  of  the  standards  and  a  hardware  and 
software  modification  to  the  original  work  (34)  to  allow  the  ring 
communicate  in  both  clockwise  and  counterclockwise  directions,  the 
DELNET  architecture  evolved  as  shown  in  Figure  1-2.  There  are  a  maximum 
of  16  UNIDs  on  any  one  dual  ring.  UNIDs  one  through  15  service  various 
local  area  networks  and  host  users.  UNID  9  is  reserved  to  connect  the 
dual  rings  of  UNIDs  together.  The  addressing  scheme  follows  the 
standards  established  In  (75)  and  is  discussed  in  greater  detail  in 
(75:Chap  2). 
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sheLf  3036  based  processor  board,  the  Implementation  was  not  completed. 
In  1933,  Matheson  (64)  followed  with  the  hardware  Implementation  and 
began  the  translation  of  the  system  software  developed  by  Phlster  Into  a 
language  compatible  with  the  Intel  development  systems.  Matheson 
discovered  during  his  preliminary  hardware  i  implementation  that  the 
network,  hardware  designed  by  (73)  would  not  work  properly  as  originally 
designed  (64).  He  then  began  an  Intensive  hardware  redesign  effort  to 
produce  a  working  hardware  design.  He  obtained  a  feasible  hardware 
design  but  at  the  cost  of  limited  software  translation  from  the  UNID  I 
system  and  test  of  the  UNID  II  system.  It  Is  at  this  point  where  the 
current  effort  begins. 

Current  Status 

A  hardware  design  for  the  UNID  It  exists  (64).  Another  alternative 
using  off-the-shelf  single  board  computers  was  Investigated  with  the 
result  that  the  UNID  II  development  could  proceed  more  reliably  using 
single  board  computers.  The  hardware  architectural  -and  Implementation 
changes  using  Intel  SBC  544  and  SBC  33/45  single  board  computers  are 
discussed  In  greater  detail  In  Chapter  Three. 

Pro  bflTm  Statement 

Integrate  the  SBC  514  and  33/45  single  board  computers  and 
Implement  the  existing  software  designs  to  produce  a  functional  UNID  II. 
Spec l f leal ly : 

1.  implement  the  integration  of  the  Intel  SBC  33/45  and  SBC 
5 i4  boards . 

2.  Convert  the  network  (data  Link  layer)  ?L/Z  software  to 
PL/M  and  validate  its  functionality. 


J.  Validate  the  functionality  of  the  already  translated 
local  (network  layer)  PL/M  software. 

4.  Integrate  the  local  (network  layer)  and  network  (data 
link  layer)  software  and  test  the  UNID  II  as  a  functional 
entity. 

5.  Integrate  into  and  test  the  UNID  II  In  the  DELNEr. 

Scope 

The  SBC  33/45  and  SBC  544  single  board  computers  will  be  checked 
for  functionality.  Development  and  implementation  of  the  necessary 
software  to  validate  the  functionality  of  the  SBC  544  and  the  SBC  33/45 
boards  as  a  single  functional  entity  will  follow.  Conversion  of  the 
remaining  UNID  I  PL/Z  software  to  PL/M  and  Its  functional  validation  is 
the  next  step,  followed  by  a  functional  simulation  of  the  UNID  II 
software  on  the  Intel  ISIS  software  development  system.  Integration  of 
tne  local  and  network  software  and  Its  functional  validation  on  tne  UNID 
II  is  next  witn  the  Integration  and  test  of  the  UNID  II  In  the  DELNET  is 
tie  last  step. 

\  ssumptlons 

1.  It  is  assailed  that  the  local  and  network  boards  work 
properly. 

2.  It  Is  assumed  tnat  the  local  software  design  is 
previously  developed  and  translated  functions  properly. 

3.  It  is  assumed  that  the  network  software  design  as 
developed  functions  properly. 

Summary  of  Current  Knowledge 

The  most  up  to  date  summary  of  the  UNID  and  the  DELNEr  Is  described 
in  detalL  in  Phlster  (75).  The  background  in  this  chapter  gives  a 
chronological  history  of  tne  development  of  the  UNID.  The  curcent 


status  of  the  UVtO  II  Is  described  above.  Detailed  Information  may  be 


found  Ln  the  bibliography. 

Standards 

The  standards  used  in  this  thesis  effort  will  follow  those  used  for 
the  DELNEr  and  the  UNTO  l  as  developed  by  Pnlster,  et  al,  In  their  work. 
These  standards  Include: 

1.  ISO  Open  Systems  Reference  Model  DP-7490. 

2.  CCITT  X.l,  X.2,  and  X.95  for  Class  of  Service. 

3.  CCITT  K . 121  for  routing  control. 

4.  Transmission  Control  Protocol/Internet  Protocol  (TCP/IP). 

5.  CCITT  X.25  for  network  control. 

6.  ISO  3309-1976(E)  for  data  link  control. 

7.  dlgh  level  Data  Link  Control  (HDLC)  protocol. 

3.  CCITT  LAPB. 

9.  RS-232C,  RS-422  and  RS-449  3t  the  physical  layer. 

The  standards  are  International  and  national  In  their  scope  and 
application  and  will  be  followed  as  previously  Implemented  to  maintain 
compatibility  with  the  UNID  l  and  other  data  processing,  teleprocessing, 
and  telecommunication  equipments.  The  standards  will  reviewed  in 
further  detail  in  Chapter  Two. 

Approach 

The  first  step  will  oe  to  simulate  the  functionality  of  the  local 
(network  layer)  and  network  (data  link  layer)  software  modules.  This 
will  be  accomplished  on  the  Intel  System  III  In  tne  Computer 
Communications  and  Networks  Laboratory.  The  l  npu t/ ou tpu t  (I/O) 
requirements  of  the  software  can  be  satisfied  by  the  use 


of  the  ISIS 


operating  system  functions.  The  software  can  then  be  validated  and 
corrected  as  necessary  without  the  use  of  the  target  hardware.  This 
approach  allows  a  'simpler'  and  time  efficient  software  development  and 
validation  phase. 

The  second  step  Is  to  Incorporate  the  target  system  Initialization 
software  Into  the  local  and  network,  software  developed  la  the  first 
step.  A  final  software  module  Is  built  which  can  then  be  programmed 
Into  EPROMs  for  the  SBC  544  and  SBC  33/45  boards.  A  C?/M  system  will  be 
used  to  simulate  a  local  host  for  the  software  validation  hosted  on  the 
single  board  computers. 

The  third  step  Is  to  Integrate  the  UNID  LI  Into  the  DELNEI  and 
begin  the  software  validation  of  the  UNID  II  software  In  Its  Intended 
environment. 

Equipment 

The  InteL  System  III  Is  requlcad  for  PL/M  software  conversion, 
development,  and  system  software  simulation.  The  Intel  System  HI/ 2 10 
is  required  for  word  processing.  Wirewrap  tools,  wirewrap  wire, 
soldering  Iron  and  solder,  assorted  pliers  and  other  tools  are  required. 

Other  Support 

Supply  and  contracting  support  for  the  acquisition  of  Integrated 
circuits,  hardware,  software  and  other  manufacturer's  manuals  will  be 
required.  A  workbench,  desk  and  administrative  supplies  are  required. 

Conclusion 


The  chapter  began  with  the  history  of  the  Digital  Engineering 
Laboratory  Network  (OELNET)  and  the  Universal  Network  Interface  Device 


(UMID)  I.  [t  then  covered  the  current  status  of  the  UNID  II,  problem 
statement,  scope,  assumptions,  standards,  approach,  equipment,  and  other 
support  required  for  the  further  development  and  implementation  of  the 
U M I D  II  to  a  working  system.  The  next  chapter  discusses  the  'JNID  II  and 
OELNET  requirements. 


LI.  UNID  II  and  DELNET  Requirements 


Introduction 


This  chapter  summarizes  the  requirements  established  In  previous 
thesis  work  (JO,  75,  64).  A  summary  of  the  UNID  II  requirements  Is 
first  followed  by  a  summary  of  the  DELNEr  requirements.  This  summary  is 
repeated  in  large  part  from  Matheson's  work  as  no  new  requirements  have 
been  established  nor  deleted  except  as  noted  later  In  the  chapter. 


UNID  II  Requirements  Summary 

The  original  UNID  design  was  based  on  the  following  general 
criteria  (,34): 

1.  The  UNID  should  function  as  a  store  and  forward  concentrator 
and  have  message  routing  capabilities. 

2.  The  UNID  might  require  specialized  I/O  ports  foe  unique 
communication  requirements. 

3.  The  iJNID  should  be  capable  of  interlacing  to  various  network 
operating  systems  and  protocols. 

4.  The  UNID  should  provide  an  environment  for  computer 
communication  network  studies. 

these  concepts  ace  still  valid  and  are  the  primary  design  goals  tor 
the  UNID  II.  The  UNID  II  Is  projected  to  be  used  in  the  DEL NET.  The 
UNIQs  are  configured  in  a  dual  ring  with  the  host  systems  forming  a  stir 
at  each  node.  However,  the  UNID  should  be  designed  to  interface  with 
other  network  conf iguratlons  which  could  be  Implemented  at  i  liter  date. 
The  UNID  nardware  should  be  as  flexible  is  possible  so  that  changes  In 
network  protocols  can  be  done  in  software  or  firmware  rather  than  by 
changing  or  redesigning  the  hardware. 

At  the  lowest,  or  ’Hardware,  level  of  protocol  the  Interfaces  have 
been  defined  to  conform  with  toe  El  A  <3-2320  (13)  and  RS- 4 49  (19) 


standards.  The  Local  Interfaces  to  computers  or  terminals  wiLl  use  RS- 
2  32C  and  the  netwock  Interface  between  UVIDs  are  configured  for  RS-422 
and  US-449.  higher  Levels  of  protocol  should  Interface  so  that  changes 
in  the  upper  levels  can  be  accommodated  with  changes  in  LIVID  software 
rather  than  hardware.  The  various  levels  should  have  clearly  defined 
interfaces  to  make  updates  and  changes  easier  and  faster. 

Structured  analysis  and  design  techniques  (SADTs)  were  used  to 
develop  the  functional  requirements  of  the  original  iJNID  (84).  A  design 
using  a  modular  approach  was  than  developed.  Three  separate  hardware 
modules  were  identified:  (1)  a  local  input/output  (I/O)  nodule  for 
interfacing  the  UN1D  to  the  user's  computers,  terminals,  or  modems;  (2) 
a  netwock  I/O  module  for  interfacing  the  iJVID  to  other  UrtlDs  over  the 
network;  and  (3)  a  dual  processor  module  for  matching  the  local  I/O  to 
the  network  environment  (84:154-135).  The  three  module  types  were 
selected  after  analysis  of  the  requirements  using  SAi)T  methods  (34:11- 
31). 

In  1931,  a  thesis  effort  was  begun  to  design  an  improved  iJh’ID,  the 
3086  based  UNID  ii.  The  original  functional  requirements  (34,  32)  were 

used  to  produce  data  flow  diagrams  (DFDs)  (30),  and  a  new  functional 
requirements  model  was  developed  for  the  UNID  It.  The  requirements 
which  were  used  to  develop  the  requirements  model  are  listed  in  Table 
L I  —  I .  The  result  Indicated  that  two  distinct  groups  of  requirements 
•were  present.  One  group  dealt  with  the  handling  of  local  nessages  and 
the  other  with  the  handling  of  network  messages.  While  thece  were  many 


simllarltlas  in  function,  both  gcoups  were  considered  necessary.  The 
DFDs  served  as  the  basis  for  the  design  of  the  IJN’ID  [I  and  are  of 
sufficient  detail  to  aLd  in  the  implementation  of  the  'JJIO  Li.  The 


ori.gi.nal  OFDs  ara  coproduced  tu  Appendix  A. 

Table  II-I.  iJNIl)  11  Requirements  (64) 


Interface  a  wide  variety  of  network  components  and 
handLa  various  topologies. 

A.  Accommodate  dissimilar  computing  equipment 
L.  Accomplish  coda  conversion 

2.  Perform  data  rate  spaed  conversion 

8.  Interface  peripherals  and  user  terminals  to  the 
ne  twork 

C.  Interface  host  computers  to  the  network 
0.  Provide  a  network  to  network  Interface  (a  gateway) 


Perform  Independently  of  network  components 

A.  Handle  network  data  transmission  and  reception 

1.  Accommodate  netwock  throughput  requirements 
and  flow  control 

2.  Adapt  to  different  protocols 

a)  Handle  ooth  synchronous  and  asynchronous 
communication 

b)  Edit  and  pack  characters  Into  formatted 
messages 

c)  Unpack  a  message 

i)  Perform  parallel  to  serial  and  serial  to 
parallel  data  conversion 
e)  HandLa  error  control  functions  such  as 
message  acknowledge,  no  acknowledge, 
cepeat,  and  tlmout 

3.  Perform  error  checking  and  recovery  procedure 

3.  Relieve  host  computers  from  network  specific 
functions 

1.  Provide  a  buffer  to  smooth  message  traffic 

2.  PoLl  communications  lines  it  they  are 
mul t Idropped 

3.  Handle  interrupts 

4.  Route  messages  to  desired  destinations 

5.  CoLlect  perf ormance,  traffic,  and  error 
statistics 


Provide  a  testbed  for  computer  network  studies  and  re 


PELMET  Functional  Requirements 

A  survey  of  potential  DELNET  usees  was  taken  in  1981  is  part  of 
another  thesis  effort  (32).  The  responses  to  the  survey  were  used  to 
formulate  a  set  of  functional  requirements  for  the  DELNET.  A  summary  of 
the  requirements  which  were  considered  to  be  the  most  important  are: 

1.  Ability  to  transfer  files  across  the  network. 

2.  Ability  to  share  peripherals  attached  to  the  hosts  on  the 
PELMET. 

3.  Flexibility  with  respect  to  the  network  topology,  protocols, 
and  transmission  media. 

4.  Performance  monitoring  capability. 

5.  High  percentage  of  availability. 

6.  User  transparency  to  network  configuration  and  specific 
operating  systems  of  hosts. 

Other  additional  features  were  identified  in  the  survey  but  were 
not  considered  as  important  for  the  initial  implementation.  Some  of  the 
identified  features  which  miy  be  considered  in  the  future  include: 

1.  Permit  software  tool  sharing. 

2.  Perform  distributed  processing. 

3.  Use  distributed  databases. 

4.  Incorporate  fault  tolerance, 

‘3.  Provide  a  naans  to  connect  to  other  networks  such  as  the 
AFir.VET  and  ARPANET. 

6.  Connect  to  the  local  Cyber  730  and  DEC  VAX  11/780  (Unix). 

7.  Pcovida  data  privacy. 

8.  Provide  security  tor  classified  projects. 

WhLle  providing  security  for  classified  projects  Ls  a  desirable 
goal,  it  is  not  within  the  scope  of  the  DELNKT  nor  the  (JNIOs  to 

Air  Force  and  other  securLty  directives 


accomplish  this  goal. 


I implemented  oy  the  Electronic  SecurLty  Com, land  (ESC)  -/111  not  approve  a 
secure  network  In  the  \  F  E  T  environment  due  to:  lack  of  physical 
security;  lack  of  TEMPEST  approved  equipment;  and  lack  of  trusted 
computer  software,  and  it's  associated  hardware,  validated  and  approved 
by  the  National  Security  Agency  (MSA).  Providing  data  privacy, 
including  user  au  t’nentication  and  verification  procedures,  for  the 
0 ELM ET  users,  also  desirable  goals,  Is  within  the  scope  and  pervue  of 
the  UELNEf  and  the  UNIDs.  Recommendations  In  this  area  are  discussed 
further  In  Chapter  Six. 

Utilizing  the  user  generated  list  of  functional  requirements,  a  set 
of  requirements  for  the  DELMET  hardware  and  software  was  established.  A 
ring  topology  was  Initially  selected  for  the  DELMET  connections  with 
each  node  providing  a  star  subnet  to  the  local  users.  This  is  the  same 
basic  configuration  recommended  in  the  1342  EEC  Technical  Report  (1)  for 
base  level  communications  systems  except  for  the  star  subnet.  The 
report  seamed  to  Indicate  a  single  usee  it  each  network  Interface  while 
the  OF.LNET  requirement  is  for  multiple  hosts,  up  to  four  in  the  currant 
design,  on  each  network  node.  With  the  ring  topology,  development  of 
routing  algorithms  Is  easier  and  system  expansion  simplified  (37:Chap 
7),  since  an  elaborate  routing  scheme  is  not  needed  and  new  nodes  can  be 
easily  connected  to  the  network. 

The  system  requirements  outlined  in  the  original  thesis  (34) 
evolved  and  became  the  basis  for  a  series  of  additional  inves tigatloias. 
Further  refinement  of  the  DFDs  W3s  accomplished  L  3  3 ) ,  followed  by 
implementing  standards,  developing  software  procedures  and  wrLtlng  the 
necessity  coda  (29,  32  ,  7  3,  64).  At  the  same  time,  the  UN  ID  hardware 
design  was  modified  wad  refined  (4,  11,  74,  id)  to  correct  known 


problems,  Improve  reLlaDi.Li.ty  and  create  the  dual  ring  topology  of  the 
U d4 I D  network  (75).  Demonstrations  of  the  DELNET  were  accomplished  In 
1931,  1933,  and  1984  but  were  limited  due  to  the  lack  of  complete 
software  above  the  network  layer. 


Protocols 

In  establishing  the  protocol  standards  for  the  DELNET,  various 
protocols  recommended  by  both  national  and  international  standards 
organizations  were  reviewed  and  those  which  seamed  to  'best'  meet  the 
stated  requirements  were  selected.  A  packet  switching  protocol  using 
the  CGI [I  <.25  standard  was  originally  chosen  (29). 

Since  the  work  was  and  will  continue  to  be  accomplished  in  stages, 
with  flexibility  remaining  a  design  goal,  a  recommendation  was  made  and 
accepted  (32)  chat  the  ISO  GSL  Reference  Model  (12,  37)  be  used  for  the 
overall  DEL.NET  protocol  design.  The  development  of  specific  protocols 
for  the  DELNET  and  implemented  on  the  JNID  are  175): 

1.  CCITT  <.25,  LAPS  (ilDLC)  in  the  data  link  layer. 

2.  CCITT  <.25,  datagram  service  in  the  network  layer. 

i.  CCITT  <.121,  Internet  descriptions  in  the  transport  layer. 

4a.  TCP/IP  In  the  transport  layer  for  datagram  service. 

b.  Federal  Information  Processing  Standards  (FIPS)  and 

National  Bureau  of  Standards  In  the  transport  layer  tor 
virtual  circuit  service. 

Since  the  UNID  It  will  be  nodes  in  the  DELNET,  it  will  support  the 
[SO  OS I  Reference  Model.  Previous  work  (75)  estabiished  that  the  UNID 
wouLd  initially  support  a  datagram  service,  with  the  three  lower  layers 
of  the  model,  called  the  subnet,  Implemented  in  the  UNID.  The  host 


would  Lnplemont  the  uppec  four  layers.  This  particular  separation  of 


the  layers  Is  common  for  a  datagram  service  network  (87:Chap  3).  As  an 
aid  to  understanding  both  the  model  and  Its  Implementation  on  the  DELNET 
and  the  IfNlO  II,  a  orlef  description  of  the  model  and  the  above 
standards  follow. 


ISO  Reference  Model 

The  ISO  OSI  Reference  Model  Is  Intended  to  be  a  vehicle  for  the 
development  of  specific  standard  protocols  within  its  seven  layers  as 
shown  in  Figure  2-1.  The  layering  divides  a  very  complex  task,  into 
smaller  tasks  with  each  being  relatively  independent  of  the  others. 
Other  organizations,  such  as  the  National  Bureau  of  Standards,  have 
established  and  further  clarified  standards  which  operate  within  the 
framework  of  the  OSI  model  (21,  22,  23,  2d,  25,  2d,  27). 
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Figure  2-1.  ISO  OSI  Reference  Mo  lei  \pplied  to  DEL 'JET  and  UNID  (75) 


At  any  given  Layer  (except  the  physical  layer),  a  program  in  one 
Layer  communicates  with  a  corresponding  program  in  the  same  layer  in 
another  host  or  node  in  what  Ls  cilLed  a  'peer  process'.  While  the  two 
hosts  logicalLy  communicate  directly  with  eich  other  (the  Jotted  lines 


la  Figure  2-1),  ill  communications  la  fact  must  pass  through  the  lowest 
layer  slace  the  oaly  physical  conaectioo  Is  at  that  layer  (the  solid 
llaa  la  Figure  2-1).  Each  layer,  while  logically  communicating  with  Its 
peer  process  la  another  host,  provides  various  services  to  the  next 
higher  layer  above  It.  For  example,  the  physical  layer  provides  the 
physical  communications  link  services  for  the  data  liak  layer. 

The  content  of  the  applications  layer  is  determined  by  the  user 
requirements.  This  layer  may  represent  data  base  exchanges,  user  to 
user  Interactive  traffic,  or  message  traffic  as  examples. 

The  presentation  layer  handles  the  data  format  transformations 
which  can  include  data  compression,  file  translation,  end  to  end 
encryption,  and  virtual  terminal  protocols. 

The  session  layer  normally  performs  addressing  and  connection 
nanagement  of  the  network  for  the  host,  but  in  fact,  some  of  these 
Enactions  are  often  subsumed  in  the  transport  or  presentation  layers  in 
an  actual  implementation  (37:Chap  3,  Chap  *>). 

Once  the  data  is  formatted  and  addressed,  it  must  be  transmitted. 
The  transport  layer  provides  the  host  messages  to  the  communications 
facilities  for  eventual  transmission.  This  layer  should  provide  error 
free,  end  to  end  communications  between  hosts.  Some  examples  of 
services  at  this  level  Include  error  checking  and  recovery,  flow  control 
for  che  host,  sequencing  of  the  nessajes,  and  establishment  and 
termination  of  a  host  to  host  connection.  The  TCP  is  implemented  at 
this  layer  In  the  UNIDs  and  the  DtLNEf  (75:  4ppen  C). 


The  IP  protocol  Is  usually  implemented  between  the  transport  and 
network  layers  to  Interface  networks  with  different  protocols  and  data 
entity  formats  through  a  common,  standard  protocol  (37:  Chap  3).  The 


most  common  implementation  of  the  IP  Is  where  two  different  networks  are 
connected  through  a  gateway.  A  gateway  Is  a  set  of  computer  hardware 
and  software  programs  through  which  two  different  networks  can 
communicate.  The  most  common  implementation  of  a  gateway  is  where  the 
functions  of  the  gateway  are  divided  in  half  and  Implemented  at  nodes  of 
the  two  different  networks.  The  IP  protocol  is  implemented  as  the 
common  protocol  between  the  gateways  and  the  next  higher  and  lower 
layers,  the  transport  layer  and  the  network  layer,  respectively.  The  IP 
protocol  is  effectively  sandwiched  between  the  transport  and  network 
layers,  forming  another  layer  that  could  be  called  the  internet  layer, 
layer  threa-and-one-half .  The  sandwiched  layer  representation  Is  shown 
In  Figure  2-2  as  applied  to  the  ISO  OSI  in  the  'JNID  and  the  DELN'ET. 
Although  the  IP  Is  used  between  two  different  networks,  it  may  also  be 
used  between  a  host  and  the  host's  servicing  packet  switching  node.  The 
IP  protocol  is  implemented  Ln  the  UNID  anl  the  OF.LNET  (75:  Appen  C). 
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Figure  2-2.  [SO  OSi  Reference  ModeL  with  the  Internet  Protocol  (IP). 


Subne  t 


The  lowest  three  layers  comprise  the  subnet.  These  layers  route 
dita  through  the  network  f  ron  one  host  to  another  while  the  higher 
levels  are  concerned  with  the  dialogue  between  the  communicating  host 
peec  processes.  In  the  OELNET  and  UNID  applications,  the  UNID  contains 

the  subnet  protocols.  The  access  protocol  selected  for  the  subnet  Is 

the  X.25  recommendation  of  the  CCITT.  This  standard  was  chosen  to 
establish  and  maintain  compatibility  with  other  networks.  This  protocol 
standard  describes  the  Interface  and  procedures  for  packet  switched 
service  and  is  defined  in  three  independent  architectural  leveLs  which 
are  commonly  used  for  the  three  subnet  layers.  Each  of  the  subnet 
layers  Is  discussed  in  some  detalL  because  they  encompass  the  software 
and  hardware  functions  of  the  UNID. 

Network  Layer 

The  network  layer,  referred  to  as  the  packet  level  by  the  CCITT,  Is 

the  top  level  of  the  subnet  and  Is  primarily  responsible  for  routing, 

sequencing  and  flow  control.  It  determines  the  path  that  a  massage,  or 
packet,  shouLd  take  through  the  network  from  the  originating  host  to  the 
destination  host.  In  most  networks  the  two  host  computers  may  be 
separated  by  nodes  which  are  not  directly  connected  In  the  particular 
connection.  Thera  Is  usually  more  than  one  path  between  the  two 
connected  hosts,  as  well.  Each  node  Ln  the  network  must  determine  which 
way  to  send  the  data  so  that  It  will  reach  the  Intended  destination. 

In  the  1930  revision  of  the  X.25  standard,  some  significant 
technical  enhancements  were  made  (23).  Two  of  the  most  Important  to  the 
OELNET  and  the  UNID  are:  the  addition  of  provisions  for  datagram  service 


and  the  addition  of  a  fast  seLect  facility  to  the  virtual  call  service. 


Datagrams  are  self-contained  packets  which  contain  sufficient 
address  information  to  be  routed  to  their  destinations  without  the 
establishment  of  a  virtual  circuit  through  the  subnet.  Virtual  circuit 
call  establishment  procedures,  with  their  attendent  overhead,  ace  not 
needed  since  the  datagram  is  considered  a  complete  message  unto  Itself 
and  independent  of  ail  others  in  the  network.  The  fast  select  facility 
provision  allows  a  full  123  bytes  of  user  dat-i  to  be  exchanged  during 
the  call  set  up  and  cLearlng  procedures  for  a  virtual  call.  \  more 
detailed  description  of  these  services  can  be  found  in  tne  literature 
(23,  75,  37). 

The  network  layer  must  aLso  deal  with  congestion.  The  network  can 
become  overloaded  if  the  hosts  Initiate  data  into  the  network  faster 
than  it  can  be  processed  and  delivered.  Some  method  of  controlling  the 
mount  of  data  in  the  network  has  to  be  used.  One  of  the  more  common 
nethods  is  the  exchange  of  flow  control  messages  -with  the  network  layers 
of  other  nodes.  These  messages  can  Include  Information  such  as 
acknowledgement  of  receipt  of  data,  the  number  of  free  message  buffers, 
or  the  fact  that  the  node  Is  unable  to  receive  data  at  the  present  time 
(37).  These  features  are  not  as  yet  implemented  In  the  IJNID. 

Messages  fron  the  transport  layer  nay  have  a  priority,  and  if  so, 
it  is  the  task  of  the  netwock  layer  to  Insure  that  higher  priority 
messages  are  haniled  first.  it  must  also  deliver  liigh  priority  nessages 
to  the  transport  layer  first  before  lower  priority  messages  are 


Data  Link  Laye c 


The  lata  linK  layer  combines  groups  of  bits  Into  Logical  units 
called  frames.  It  Is  the  function  of  the  data  Link  layer  to  create, 
recognize,  and  controL  the  flow  of  the  logical  bits  transferred  to  and 
Eron  the  network  and  physical  layers.  The  bit  oriented  link  access 
control  procedure  specified  In  the  X.25  standard  Is  the  Link  Vccess 
Procedure  B  (LAP3),  which  Is  equivalent  to  the  ISO  dlgh  Level  data  LLnk 
Control,  HDLC,  standard  (23).  The  frame  format  specified  by  the 
standard  and  Implemented  In  the  DELVET  and  the  LIVID  tl  Is  shown  Ln 
Figure  2-3.  The  figure  represents  a  composite  of  the  UDLC  protocol,  X.25 
protocol  with  the  datagram  service  option,  and  the  TCP/IP  used  in  the 
software  Implementation  of  the  UK  IDs  l  and  LI. 
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Defease  computer  networks  and  a  required  protocol  tor  DoD  computer 
networks,  is  partiiLLy  implemented  in  the  transport  layer  of  the  UNIDs  I 


and  LI.  The  source  and  destination  addresses  .are  shown  for  each  of  the 
frame,  packet,  and  datagram  where  each  structure  is  broken  into  smaller 
segments  to  show  its  respective  contents.  The  control  (CT),  country 
ICC),  network  (NC),  host  (HC),  and  port  (PC)  codes  are  shown  for  the 
implementation  of  the  CCITT  X.121  standard  in  the  IP  header  used  with 
the  UMIDs.  I  more  detailed  description  of  the  header  structure  and 
contents  is  in  Appendix  D  and  (75:  Appen  C). 

Since  the  data  link  layer  can  receive  bad  data  from  the  physical 
iayar,  an  error  detection  capability  is  Included.  A  set  of  16  bats 
nased  on  cyclic  redundancy  check  (CRC)  calculations,  often  called  a 
checksum,  Is  appended  to  the  address,  control  .and  information  bits  as 
they  are  sent.  This  checksum  is  compared  with  a  Locally  generated 
checksum  at  the  receiving  node.  When  the  checksums  match,  then  Lt  is 
assumed  that  the  received  frame  is  correct,  otherwise  the  receiver  snows 
that  an  error  has  occurred  during  transmission  and  the  transmitter  is 
aot  I led  to  retransmit  that  particular  frame.  The  i  e  t  a  i  l  s  of  C  li  C 
calculation  are  explained  in  the  X.25  standard  (23),  while  tiae 
mathematics  involved  are  explained  in  the  Literature  <37,  62).  Figure 

2-3  does  not  show  the  flag  or  checksum  bits,  even  though  they  are 
present,  as  these  ace  automatically  calculated,  added,  and  deleted  by 
the  digital  transmitter  and  receiver  hardware  at  the  network  physical 
level.  The  flag  bits  are  also  appended  to  the  data  link  layer  frame. 


These  flag  bits  are  used  for  synchronic lug  the  hardware  to  the  beginning 
ind  •ending  of  the  dati.  Both  the  flag  and  the  CRC  bits  are  usual  ly 
appended  and  deleted  an  tuna t in  a Lly  by  the  physical  level  hardwire.  This 


hardware  method  is  Implemented  La  the  UNID  LI  hardware. 
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Physical  Layer 

The  physLcaL  Layer  is  the  lowest  level  La  the  network.  It  provLdes 
the  physical,  electrical,  mechanical,  functional,  and  procedural 
services  to  define  the  physical  connection  between  network  nodes.  The 
physLcaL  interface  standard  referenced  by  the  C  0 1  IT  for  the  host 
computer  to  network  node  is  the  T.21  digital  interface  standard.  The 
standards  between  network  nodes  are  not  defined  by  CCLTT  for  the  K.25 
standard,  therefore,  the  RS-422  and  RS-449  standards  are  used  in  the 
TELNET  between  the  UN  IDs  to  maintain  standardization.  The  host  computer 
or  user  device  is  defined  as  the  lata  terminal  equipment  (DTE)  and  the 
network  node  (the  UNID)  is  considered  data  communications  equipment 
(DOE).  While  the  X.21  standard  is  not  widely  implemented  nationally  or 
internationally  due  to  the  tack  of  true  digital  communication  systems, 
ciie  <.21(bis)  is  often  used  in  its  place.  The  T.21(bls)  standard  is 
used  to  interface  digital  equipment  with  analog  communication  systems. 
While  the  united  St3tes  generally  does  not  use  the  T.2i(bis)  standard, 
the  2.3-2  32C  standard  is  most  often  used  in  its  place  as  the  .13-  2  32  3 
standard  is  functionally  equivalent  to  the  T.Zl(bis)  standard  (d7/.  The 
15-2320  standard  is  the  standard  Implemented  between  the  host  and  the 
liNIDs  in  the  TELNET.  The  original  work  of  Siuzevich  (54)  inc Laded  a  20 
n i 1 1 i ampere  current  loop  as  a  highly  Likely  physical  Interface  between 
the  O'.NIO  and  certain  host  equipments.  This  requirement,  while  valid  in 
19  7 -‘3  and  earlier  when  a  considerable  amount  of  equipment  using  this 
Interface  existed,  is  no  longer  valid  and  will  not  be  i  nplemented  on  the 
U  M  ID  11.  "lost  of  the  20  millL ampere  current  loop  equlpneiat  'a  a  s  been 
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replaced  with  newer,  more  advanced  equipment  using  the  RS-2J2C  and  MiL- 
3TD-133  standards,  even  in  military  communication  environments. 
Appendix  3  shows  the  actual  RS-232C  and  33-422  signals  used  in  the 
DELJ'Zr  and  UMID  Li. 

Conclusion 

This  chapter  summarized  the  requirements  tor  the  Unit)  It  and  the 
hELMET.  The  ISO  0S1  Reference  Model  and  K.25  protocol  standard  were 
introduced  and  their  correlation  to  the  UMID  it  functions  was  briefly 
explained.  The  requirements  in  Table  1 1—  I  and  data  flow  diagrams  of  the 
functional  requirements  model  in  Appendix  A  form  the  basis  for  the 
design  and  implementation  of  the  UMLD  II.  Chapter  Three  discusses  the 
UNI)  II  hardware  design  and  implementation. 


III.  UN  ID  1 1  Hardware  Design 

introduc  tlon 

Inis  chapter  deals  with  the  hardware  design  of  the  UNID  It.  The 
previous  designs  (30,  73,  64)  are  first  reviewed  to  show  the  design 
evolution.  The  current  design  is  then  discussed  in  light  of  the  past 
designs.  i’ne  strengths  and  weaknesses  of  each  design  are  reviewed. 


initial  Designs 

The  initial  JNID  li  design  began  in  1931  (30).  fne  investigation 
centered  around  several  possible  configurations  for  the  implementation 
of  a  UNID  II  using  trie  Intel  3036  family  of  processors  as  a  successor  to 
tee  UNID  t,  which  was  based  on  the  Zilog  Z30  processor.  The  3035  family 
of  processors  was  Investigated  for  use  with  the  UNID  II  because  of  their 
increased  processing  power  and  ability  to  generate  relocatable  code. 
I  he  final  preliminary  design  is  shown  In  Figure  3-1  (30:Fig  3-4).  This 
con.:  I  gu  rat  l  on  has  two  hardware  subsystens,  the  network  and  local 
subsystems,  to  allow  each  subsystem  to  be  relatively  Independent  of  the 
jyate  :i  multibus.  The  network  subsystem  consists  of  the  3036  tad  3039 
processors  with  the  associated  Input/output  (1/0)  hardware,  private  bus 
interface  circuitry  and  memory  md  multibus  interface  circuitry.  The 
local  subsystem  consists  of  the  four  cn.annel  serial  1/0  and  a  3036 
processor.  In  addition  to  the  general  system  requirements  (see  Chapter 
rwo  of  this  thesis),  tile  lesLgn  was  guided  "To  allow  the  network, 
subsystem  to  oe  relatively  Independent  of  the  system  bus,  (therefore) 
the  network  subsystem  contilns  in  303o  CPU  ind  sLive  3039  (30:63)." 
Tills  design  1 11  owed  network  I/O  to  be  handled  by  one  subsystem  while  the 
l  mil  I/O  w.'ul  i  he  n  milled  bv  the  other  subsystem.  t'.ie  lestgn  also 


Multibus 


aLLowed  a  network  and  Local  software  to  be  phystcaLLy  as  weLl  as 


logically  separated  and  hence,  added  another  degree  of  modularity  in  the 
software  design.  The  Largest  contribution  to  the  UMIQ  II  effort, 
however,  was  actually  twofold.  Mot  only  was  a  completed  preliminary 
design  for  the  8036  based  UMID  II  provided,  but  a  functional  analysis 
which  led  to  the  data  flow  diagrams  in  Appendix  A  (30:26-34)  was 
completed  as  well.  Processor  to  processor  data  transfers  were  specified 
to  be  from  data  buffers  Ln  shared  memory.  These  buffers  were  separate 
from  the  receive  and  transmit  data  buffers  and  functioned  as  a  FIFO 
queue.  Pointers  and  semaphores  were  included  in  block  headers  tc 
synchronize  the  co nmunlca tion  between  the  3036  and  3039  processors.  The 
software  design  is  discussed  in  greater  detalL  Ln  Chapter  Four.  More 
detailed  analysis  nay  be  found  in  reference  (30). 

Original  Implementation 

The  accuai  hardware,  as  implemented  (30),  became  three  circuit 
curds  Ln  m  Intel  multibus  card  rack.  The  Implementation  followed  from 
the  preliminary  design  in  Figure  3-1  'exactly'.  The  local  processor  was 
in  Intel  36/ 12 A  single  board  computer.  The  tour  channel  serial  I/O  card 
was  interfaced  to  the  $30  3  5/  1 2  A  through  the  parallel  port  of  the  S3C. 
The  3036/3039  card  w is  i  locally  constructed  wirewrap  card  which  tit  in 
the  multibus  cacd  cage.  The  ictuul  circuit  design  was  based  on  an  Intel 
lpplieitLona  note  (33).  Data  transfer  fro  a  tne  local  host  was  through 
the  four  channel  sect  il  card  connected  to  the  33C  3o/12A  through  the 
parallel  port.  The  data  was  then  manipulated  appropriately  and  put  in 
system  shared  memory  and  then  tiie  network  card  was  interrupted  to 
service  the  data  in  the  shared  memory.  The  303o/J039  board  would  then 


manipulate  the  data  and  send  the  data  to  the  3039  and  I/O  hardware. 
Note  that  alL  the  data  transfers  between  the  hosts  and  the  SBC  86/12A 


were  through  eight  bit  universal  synchronous/asynchronous 
receiver/tr ansmitters  (USAAT)  and  the  eight  bit  parallel  port  of  the  SBC 
J6/12A,  even  though  the  data  was  further  manipulated  by  a  16  bit 
processor.  After  the  SBC  36/124  manipulated  the  Incoming  host  data,  it 
would  send  the  data  to  the  8086/3089  card  through  reserved  blocks  of 
memory  in  the  shared  memory  space.  The  multiple  protocol  communications 
controllers  (MPCC),  while  allegedly  capable  of  handling  16  bit  data 
transfers,  can  in  fact  only  handle  eight  bit  data  transfers  (20:5-267) 
The  lPCCs  on  the  market  at  that  time  were  capable  of  interfacing  with  a 
lo  bLt  processor,  however  the  actual  data  transfer  was  eight  bits  of 
data  and  eight  oits  of  status  or  control  information.  The  end  result  is 
chat  the  data  transfers  to  aau  from  the  MPCCs  and.  the  processor  are 
still  eight  bit  data  transfers.  The  dPCCs  available  on  the  market  as  of 
mil  1 9 3 4  are  still,  with  the  possible  exception  of  very  specialized 
Integrated  circuits,  desLgned  with  eight  bit  data  paths.  The 
i  implementation  did  produce  a  minimally  functioning  system,  however  the 
progress  was  hampered  by  wiring  errors  which  were  discovered  during  the 
network  board  checkout  phase  (  7  3  :  C  h  a  p  4).  The  only  software 
implemented  at  triis  time  was  cor  use  with  checkout  and  test  of  the 
circuit  boards.  More  detail  may  be  found  in  reference  (73). 

devised  implementation 

Furtner  efforts  (64)  continued  the  'JN'ID  II  Implementation.  DurLng 
the  initial  review  of  the  design,  it  was  ilscovered  that  the  original 
design  would  not  work  properly.  The  main  problems  were  Incompatible 


add  r  ass  mapping  t ti  the  SU86/8089  board  (64:3-11)  and  the  fact  that  tha 
3089  can  handle  only  two  external  I/O  devices.  While  there  are  only  two 
MPCCs  on  the  board,  each  has  a  transmit  and  receive  section  which  must 
be  serviced  by  the  3039.  There  were  essentially  four  devices  to  be 
serviced  by  hardware  that  could  only  service  two  devices,  therefore  a 
second  8039  was  chosen  in  lieu  of  the  3036  processor.  The  redesign 
efforts  resulted  in  a  complete  hardware  design  for  the  network  board. 
The  four  channel  local  host  board  was  still  interfaced  through  the  33C 
36/12A  parallel  port.  Figure  3-2  shows  revised  U'ilD  II  design  (64:Fig 
?).  A  monitor  progcam  was  put  into  EPkOd  tor  the  SBC  So/  1 2 A  board  to 
eventually  minimise  use  of  the  In  circuit  emulator,  the  ICE  86  (41),  and 
the  local  side  software  was  translated  from  PL/Z  to  PL/3  (64).  The  work 
concluded  with  a  functional  validation  of  the  local  subsystem  hardware 
md  software.  The  converted  UNID  I  code  was  only  cursorily  validated, 
.fore  detail  may  be  found  in  reference  (64). 
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It  Block  Diagram  (Revised)  (64:1-9) 


Currant  Implements tlon 

fhe  current  Implementation  maintains  the  same  basic  architecture  as 
the  original  and  revised  designs  (30,64).  The  main  difference  Is  In  the 
hardware  l mp la m a n t a 1 1 on.  The  current  design  utilizes  off  the  shelf 
single  board  computers  (38Cs)  manufactured  by  Intel.  These  two  SBCs, 
the  IS3C  33/45  and  the  1SBC  544,  are  designed  specifically  for  a  data 
communications  environment  (46,  47).  The  choice  of  Intel  as  a  source 
of  the  3BCs  was  due  to  the  S3C  availability.  Other  manufacturers,  such 
as  Advanced  Micro  Devices  (AMD),  could  have  comparable  hardware  although 
a  search  of  other  manufacturer  products  was  not  conducted.  The  choice  of 
the  Intel  38Cs  snouid  not  be  taken  as  an  endorsement,  either  expressed 
or  impLied,  that  Intel  products  are  the  vmest'  choice.  The  selection 
should  be  i made  in  light  of  the  .system  requirements. 

fhe  current  architecture  Is  shown  in  Figure  3-3.  The  heart  of  the 
design  consists  of  an  3033  processor  servicing  two  high  speed  MPGCs 
through  a  direct  memory  access  (DMA)  arrangement  for  the  network 
interface  and  an  3035  processor  servicing  four  interrupt  driven  03  A:<T3 
for  the  local  host  interface.  Both  boards  have  (up  to  16k  bytes)  shared 
memory  and  private  memory  segments  as  well  as  Electrically  Programmable 
’.lead  Only  Memory  (EPTOM)  (3k  to  64k)  which  was  only  partially  designed 
in  the  previous  designs.  I'he  use  of  the  DMA  on  the  high  speed  network 
board  fullfills  the  'O.MA-Ilxe'  operation  (39)  of  the  303  9s  in  the 
revised  design.  fhe  Interrupt  capabilities  used  on  the  3035  based  local 
board  simplifies  the  software  design  and  i  m  p  Le  me  ra  ta  t  ion  of  the  USAAf 
supporting  software.  Each  38C  has  spare  counter / ti me rs  which  nay  oe 
used  for  real  time  counters,  timers,  or  clocks  to  support  the  timeouts 
enquired  of  the  network  and  data  link  layer  protocols.  More  detailed 
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explanation  of  the  JBC  may  be  found  In  references  (46,  47). 


[ne  use  of  these  S  3  C  s  eliminates  the  hardware  design, 
Implementation,  and  hardware  debug  phases  of  an  ln-house  design  effort. 
Che  hardware  reliability  of  a  known  hardware/sof tware  manuf acturer,  the 
availability  of  the  software  development  tools  (a  full  screen  editor, 
the  PL/h  compiler,  3035  and  8086  assemblers),  the  availability  of  PL/380 
and  PL/M36,  both  high  order  languages,  and  the  ease  of  hardware 
expansion  to  support  software  expansion  lead  to  this  implementation 
decision. 

Conciusion 

This  chapter  explained  the  hardware  design  of  the  U  N  l  D  II.  Che 
previous  designs  (JO,  73,  64)  ware  first  reviewed  to  show  the  evolution 
of  tne  design.  The  current  design  was  then  discussed  in  light  of  the 
past  designs.  The  strengths  and  weaknesses  of  each  design  were 
reviewed.  Chapter  Four  discusses  tne  UN  10  ii  software  design  and 
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IV.  UN  ID  I_I  Sot  tware  Das  ign  and  Implementation 


Introduction 

This  chapter  discusses  the  detailed  design  and  implementation  of 
the  di'JID  II  software.  I’he  discussion  is  divided  into  six  sections  based 
upon  the  top-down  design  approach:  Development  Language  Selection;  UMID 
It  Data  Structures;  UNID  II  Network  Layer  Software  Design;  UNID  II  Data 
Link.  Layer  Software  Design;  (JNIO  It  Software  Development  Tools;  and  UNID 
[£  System  Memory  Map. 


Development  Language  Selec  tlon 

The  development  language  used  for  the  the  UNID  It  is  a  high  order 
Language  called  ?L/M,  a  subset  of  ?L/1.  The  choice  of  a  high  order 
language  versus  assembly  language  foLlows  current  software  engineering 
trends:  modularity,  ease  of  design  and  maintenance,  ease  of 
unders tending,  self  documenting  ability,  well  defined  module  interfaces, 
cade  and  data  aiding,  and  simple  parameter  passing.  4  small  issamoly 
Language  module  was  used,  however,  in  a  supporting  test  program  due  to 
tne  fact  that  the  particular  module  requirements  were  satlsifled  by  a 
known  working  and  reliable  module.  Chapters  Five  and  Six  address 
tasting  in  farther  detail. 

Ihe  choice  of  ?L/M  is  simply  pragmatic:  the  compiler,  other 
software  tools,  and  the  development  system  on  which  to  run  them  were 
available  in  the  Air  Force  institute  of  Technology  computer  networks 
development  laboratory.  While  both  Pascal  and  C  compilers  were 
available  for  the  3035  processor,  neither  were  available  for  the 
3 036/3033  processors  at  the  start  of  this  investigation.  And  while  both 


Pascal  and  C  coul 1  be  used  in  future  enhancements  of  the  UNID  software 
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development,  this  author  recommends  the  use  of  C  last-;  id  of  Pascal 
because  of  C s  ability  to  manipulate  data  it  the  bit  and  byte  leveL  and 
the  availability  of  C  on  many  UNtD  nost  systems.  Pascal  cannot 
adequately  manipulate  data  at  the  bit  and  byte  level.  Manipulation  of 
data  at  the  bit  and  byte  level  is  required  for  the  correct 
interpretation  and  manipulation  of  infor  nation  in  the  data  entity 
headers.  PL/M  Is  more  than  adequate  for  use  on  the  UNID  hardware,  i.e., 
the  S3C  J44  and  S8C  83/45,  however  further  Implementations  of  the  'JNID 
may  not  use  this  hardware  and  hence  the  software  developed  with  PL/M  is 
not  readily  transportable  to  another  hardware  system.  The  reader  is 
cautioned,  however,  that  i mp le ne n ta t 1 ons  of  the  UNID  software  Ln  any 
language  will  require  that  the  developer  write  the  low  level  software 
drivers  for  the  'JSAX Ts/ MPCCs.  The  low  level  drLvers  provided  with 
Pascii  and  G  compilers  typically  Interface  to  a  host  development  system 
operating  system  services  which  do  not  exist  in  the  UNID  software.  Low 
level  i/0  software  dclvers  may  need  to  be  written  as  well  to  support  the 
hardware  serial  lin'x  to  the  UNID. 


UNEP  i_I  Da  t a  Struc  tures 

As  previously  discussed  ira  Chapter  Two,  the  main  purpose  of  the 
UNEP  Ei  software  is  to  move  information  Eros  one  point  to  another  point 
L;i  a  timely  and  orderly  fashion.  The  means  to  accomplish  that  end, 
while  strongly  dependent  on  the  system  hardware,  is  also  highly 
dependent  on  the  system  software.  The  DFDs  Ln  Appendix  A,  while 
outlining  the  steps  to  move  the  data  and  implyLng  a  data  structure,  do 
lot  specify  or  explain  in  sufficient  detail  how  the  data  is  to  be 
organised  or  moved.  Since  the  implementation  of  the  PL/M  Language  1  “ids 
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Itself  easily  and  efficiently  Co  indexed  arrays  (56,  57)  and  previous 

sot tw  ire  implementation  at  forts  (29,  50,  64,  75)  used  indexed  arrays, 

indexed  arrays  were  chosen  as  the  data  structure  for  the  input  and 
output  buffers  from  and  to  the  Lnput  and  output  serial  ports.  The 
uctuaL  Indexed  arrays  are  Lraplenented  as  circular  first-in,  first-out 
(FIFO)  queues.  A  FIFO  linked  list  structure  could  also  be  used,  however 
dynamic  memory  allocation  for  the  linked  List  in  the  PL/M  Language  is 
not  available  and  the  implementation  details  of  how  to  implement  linked 
lists  is  not  clear  from  the  available  nanufac  tucer's  data,  therefore, 
cons  ids  cable  additional  effort  would  be  spent  developing  this  type  of 
supporting  software.  Furthermore,  this  author's  experience  with  Linked 
lists  in  the  PL/M  language  is  limited,  further  contributing  to  a  longer 
development  time  deveLoping  such  supporting  structures.  Where  it  was 
more  efficient  La  terms  of  minimizing  memory  usage,  both  for  data  tables 
and  code  size,  and  increasing  processing  speed,  the  data  is  left  in  an 
irray  and  1  pointer  to  the  current  data  is  passed  to  the  using  modules 
(ID. 

Semaphores  are  used  between  the  local  and  network  SBCs  to  protect 
critical  regions  of  executable  code  and  data  (13).  Appendix  c  explains 
in  more  detail  the  rational  for  use  of  the  semaphores  and  which  critical 
regions  of  code  they  pcotect  between  the  local  sad  network  SBCs. 

Ine  data  structure  relationships  us  implemented  in  the  earlier 
Jeveiipnent  efforts  (  32  ,  64  ,  7  5)  ire  shown  in  Figure  4-1.  The  basic 
structure  is  in  indexed  array,  or  tiole,  as  implied  by  the  DFJs  in 
\pponiL<  A.  There  are  tables  for  each  receive  (LCOxRK,  M  TQxXX)  and 
bran;  nit  (LO)xT<,  \nxT<)  port  as  well  is  cannon  tables  (LCNfTB,  MiLCTB) 
:  i  hirei  ’ii.nory.  In  addition,  the  orlgluiL  design  (,32)  Include  1  the 


size.  :>e;n  aphores  (L6EM,  MSEM)  -ire  used  Co  indicate  when  a  data  element 
is  ready  Co  be  :noved.  Appendix  E  explains  their  structure  and  use  in 
inore  detail.  Data  element  movement  occurs  only  when  an  element  must  be 
moved  from  the  receive  buffer  to  the  transmit  buffer.  4  s  in  Figure  4-1, 
Figure  4-2  also  shows  the  type  of  the  data  entity  in  each  table  3  long 
with  the  size  of  that  data  entity  below  the  tables.  The  last  lines 
indicate  where  the  applicable  OSI  layer  fits  into  the  data  structures. 
The  solid  lines  connecting  the  tables  indicate  the  data  flow  between  the 
da t  a  structures. 

U  N 1 D  1 1  Network  Layer  Software  Design 

The  basic  design  of  this  software  module  follows  the  DELNET 
requirements  elaborated  upon  in  Chapter  Two.  The  CCITT  X.25  Datagram 
orotocol  was  partially  Implemented  to  gain  a  minimally  working  software 
•nodule  (e.g.,  pass  datagrams  and  packets).  The  DoD  standard  TCP/IP 
(61,  67)  protocols  and  a  variation  of  the  CCITT  <.121  internet 

addressing  protocol  (75:Appen  0)  were  Implemented.  The  variation  is  a 
result  of  studying  the  X.121  addressing  concept  as  applied  to  the 
iddressing  space  available  in  the  IP  protocol  header.  4s  the  reader 
will  recall  from  Chapter  Iwo,  the  variant  X.121  internet  addressing 
protocol  is  imbedded  in  the  S2  bit  source  and  destination  addresses  of 
the  IP  protocol.  One  should  also  recall  that  con  aunlcatlon  between 
layers  is  accomplished  through  the  infer  nation  in  the  data  ale  lent 
he  idee.  in  addition,  the  it’,  and  its  supporting  software  in  the  UN  ID 
and  host(s),  behave  as  half  gateways  interfacing  two  networks  (37:Chap 
d). 

Che  basic  function  of  the  network  layer  is  to  accept  datagrams  cron 
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an  attached  host,  determine  the  datagram  destination  iron  the  IP 
destination  address,  and  route  the  datagram  either  to  another  host 
attached  to  the  same  UNID  or  to  the  data  link,  layer  after  constructing  a 
packet  header  for  the  data  link  layer.  Figure  A-l  in  Appendix  A  is  the 
applicable  DFD  for  this  level  of  Implementation.  The  network  layer  also 
accepts  packets  from  the  data  link  layer,  interprets  the  destination 
from  the  packet  header,  and  routes  the  resulting  datagram  to  the 
attached  host.  A  data  dictionary  Is  in  Appendix  G  and  compiled  listings 
are  in  AppendLx  T  for  the  entire  set  of  software  programs  used  In  this 
effort. 

Figure  4-3  represent  a  primitive  structure  chart  showing  the  high 
level  structure  of  the  network  Level  software. 
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Figure  4-3.  Network  Layer  High  Level  Structure  Chart. 

Figure  4-4  shows  the  structure  chart  representation  for  the 
route  Jin  procedure  and  Figure  4-5  elaborates  the  routejia  procedure  in 
plain  language  pseudocode.  The  'do'-'snd'  construct  Is  taken  directly 
from  the  PL/ d  Language  to  explicitly  delineate  a  specific  block  of  code. 
The  construct  functions  exactly  as  the  'begin'-'end'  construct  in 


Pascal.  The  route (in  procedure  routes  data  coming  into  the  UN 10  to  its 
resoectlva  destination.  the  flcst  part  of  the  code  Is  representative  of 


to  which  port  the  code  belongs.  The  second  pact  of  the  code  Is 
representative  of  the  code  for  each  of  the  two  receive  channels  from  the 
network  (data  link  layer)  software.  Again,  differentiating  numbers  In 
the  variable  names  are  used  to  delineate  from  which  network  port  the 
packet  arrived. 


if  datagram  in  receive  buffer  Chen 
do 

determine  destination  address 
if  destination  is  back  to  local  host  then 
do 

move  datagram  to  local  host  transmit  buffer 

adjust  receive  buffer  pointer 

end 

else 

if  destination  is  to  remote  host  then 
do 

if  network  done  then 

send  packet  to  network 

end 

else 

do 

increment  error  count 

adjust  receive  buffer  pointer 

and 


it  packet  from  network  then 
do 

determine  local  address 
If  legal  address  then 

move  datagram  to  local  host  transmit  buffer 
sec  network  semaphore  done 


Figure  4-5.  P.outeJIn  Procedure  Pseudocode 


The  determine  destination  addcess  (det$addr)  procedure  interrogates 
the  incoming  IP  datagram  header  to  determine  the  destination  for  that 
datagram.  If  the  destination  is  for  a  Uh'ID  other  than  that  servicing 
tiie  current  host,  the  source  address  is  also  deter, mined.  This  routing 
information  is  availabl;  through  the  use  of  global  variables  for  the 
send 5packu t  procedure.  The  sendipacket  procedure  builds  the  five  byte 
packet  hsadec  on  the  datagram  information,  moves  the  pointer  to  a 
variable  in  shared  system  memory,  and  sets  a  semaphore  to  the 
appropriate  state  and  increments  the  receive  table  pointer.  details  of 
the  use  of  semaphores  for  com  .nun  l  ca  t  ion  between  the  :>,5C  v+4  and  SBC 
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63/45  boards  ire  explained  in  Appendix  E.  If  the  datagram  is  destined 
for  3  host  on  the  same  'JNID,  only  the  destination  information  is 


I 

determined.  The  destination  information  is  then  used  with  the  move  to 
local  table  (move  to.Jlocal)  procedure  to  move  the  datagram  to  the  correct 
transmit  table.  If  an  error  exists  in  the  destination  information,  the 

I 

destination  variable  is  set  to  a  nonexistant  destination  to  indicate  an 
error  in  the  destination.  In  all  three  cases  above,  the  receive  table 
pointer  is  adjusted  to  indicate  the  movement  of  the  incoming  datagram. 

» 

If  the  semaphore  from  the  SBC  63/45  board  is  not  appropriately  set,  the 
received  datagram  is  not  processed  and  receive  table  pointer  is  not 
adjusted  for  local  to  network  data  movement.  The  datagram  will  be 

» 

interrogated  again  when  the  route$in  procedure  is  next  executed. 

The  second  part  of  the  route$in  procedure  determines  if  a  packet 
from  the  network  is  destined  for  3  local  host.  If  so,  then  the  local 

i 

host  poet  address  is  determined.  When  the  host  port  address  is  valid, 
then  the  datagram  is  moved  from  the  packet  to  the  host  transmit  buffer 
for  transmission  to  the  host.  The  semaphore  to  the  SBC  33/45  board  is 
then  sat  appropriately  to  indicate  the  packet  has  been  processed.  ;iote 
that  the  semaphore  is  set  to  indicate  completed  processing  even  though 
tiie  local  address  may  be  in  error.  Furthermore,  the  Incoming  data  is 

> 

not  moved  to  any  Local  transmit  buffer  if  the  local  address  in  the 
packet  header  is  in  error.  Similar  processing  occurred  with  the  Local 
host  to  network  movement;  datagrams  or  packets  with  incorrect 
destination  information  are  not  moved  and  are  effectively  'thrown  away.' 
The  net  effect  is  that  bad  data  is  not  allowed  to  go  through  the  UNIO; 
it  Is  destroyed. 

> 


The  sendfpacket  procedure  fills  the  packet  header  with  the 


destination  and  source  Information  determined  by  the  determine 
destination  procedure.  It  then  puts  the  pointer  to  the  current  data 
into  a  variable  In  common  system  memory  lor  the  SBC  33/45  and  the  data 
link  layer  software  to  read.  A  semaphore  is  then  appropriately  set  to 
Indicate  to  the  data  link  layer  software  executing  on  the  SBC  33/45 
board  that  a  packet  Is  ready  for  transmission  into  the  network.  The 
buffer  index  is  than  updated. 

The  determine  local  address  (de t$addr$nl)  procedure  Is  used  when  a 
packet  is  received  from  the  data  link  layer  software  destined  for  a 
local  host.  The  procedure  interrogates  the  packet  header  to  determine 
for  which  host  the  packet  Is  determined.  An  error  In  the  packet 
addressing  will  return  a  nonexistant  address  to  indicate  to  the  calling 
procedure  that  the  header  addressing  Is  in  error  and  the  packet  should 
not  be  sent  to  a  host  and  should  Instead  be  destroyed. 

!• 

The  move  to  local  table  (movetoSLocal)  procedure  receives  a  pcLnter 
to  the  current  datagram  co  move  to  the  host  indicated  oy  the  de tar mine 
local  address  procedure.  1’he  procedure  moves  the  data  Iron  the  common 
system  me nory  to  the  local  host  transmit  buffer  and  adjusts  the  buffer 
pointer  accordingly. 

The  companion  procedure  coutejout  detects  if  a  datagram  is  present 
in  the  host  transmit  buffers.  Figure  4-6  is  a  representation  of  the 
ipplicable  structure  chart. 
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Figure  4-6.  goutefOut  Procedure  Structure  Chart 
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disable  interrupts 

mask  receive  US  ART  interrupt  off 

enable  interrupts 

if  datagram  available  and  not  sending  then 
do 

if  rR TA$handshake  and  (not  sending  and  not  receiving)  then 
do 

set  transmit  request  true 
set  sending  true 
send  transmit  request 
end 

if  not  TRTA$handshake  or  (sending  and  not  receiving)  then 
do 

set  sending  true 

disable  Interrupts 

mask  transmit  USART  interrupt  on 

enable  interrupts 

end 

end 

disable  interrupts 

mask  receive  USART  interrupt  on 

enable  Interrupts 


Figure  4-7.  RoutefOut  Procedure  Pseudocode 


Figure  4-7  shows  the  plain  language  pseudo  code  tor  the  routeiojt 
procedure.  If  a  datagram  is  present,  then  the  procedure  muse  check 
certain  boolean  flags  to  determine  if  a  software  handshake  is  in  use 
with  the  desired  host.  The  term  'software  handshake'  is  used  here  to 
mean  the  process  by  which  two  communicating  programs  coordinate  and 
synchronize  the  sending  or  receiving  of  a  Jit j  entity  such  as  a 
datagram.  Some  processors,  by  virtue  of  their  hardware  and  software 
architecture,  cannot  recetve  datagrams  (or  other  data  entities)  on  a 
random  basis.  These  type  of  systems  usually  use  polled  Input/output 
schemes  as  opposed  to  interrupt  driven  I/J  schemes.  Therefore,  this  type 
of  system  cannot  reliably  receive  or  transmit  Information  untLL  it  Ls 


ready  to  do  so. 


The  means  to  communicate  to  mother  processor  chit  data 


t  cans  :n  l  ss  Lon  or  reception  Is  ready  to  commence  Is  often  accomplished 
through  a  software  handshake.  The  AFLf  LSI-11  Matwork  Operating  System 
l.'JSroS)  is  such  a  system  (31,  72)  and  will  be  discussed  In  more  detail 
related  to  UMID  II  tasting  in  Chapter  Five. 

The  software  handshake  mechanism  can  be  described  as  follows.  When 
a  host  desLres  to  send  a  packet  to  a  UMID,  It  first  sends  a  transmit 
request  (i’R)  to  the  UMID.  The  receiving  UMID  then,  when  it  recognizes  a 
II  was  sent  to  It,  will  send  a  transmit  acknowledge  (r A)  back  to  the 
host  when  It  Is  ready  to  receive  a  packet.  The  sending  host,  when  it 
recognizes  the  TA  from  the  receiving  UlMID,  sends  the  datagram  to  the 
receiving  UMID.  Thera  is  no  final  acknowledge  sent  by  the  UMID  to  the 
host  to  acknowledge  the  reception  of  the  datagram.  The  TR/TA  mecha 

The  companion  procedure  route$out  detects  if  a  datagram  is  present 
in  the  host  transmit  buffers.  Figure  4-6  is  shown  in  Figure  4-3. 
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Figure  4-3.  UNID/Host  Transmit  Reques t/ Tr ansmi t  Acknowledge  Handshake. 


The  handshake  mechanism  is  Implemented  in  the  UMID  II  software  with 


four  boolean  flags  for  each  host  port.  Four  flags  are  required  since 


both  the  host  and  the  UNID  will  send  and  receive  datagrams  using  the 
TR/TA  mechanism,  providing  a  full  handshake  for  each  direction.  The 
( J N I D  must  know  which  state  it  is  in  so  that  it  can  communicate  correctly 
with  the  host.  The  four  flags  are  Transmit  transmit  request  (TXTR), 
deceive  tcaasnLt  acknowledge  (SXTA),  Receive  transmit  request  (RXTR), 
and  Transmit  transmit  acknowledge  (fXTA).  Each  flag  has  the  value  TRUE 
or  FALSE.  The  initial  state  is  all  four  flags  FALSE.  Of  the  16 
possible  states,  the  five  allowed  states  are  shown  in  the  truth  table  In 
Figure  4-9.  A  '0'  represents  FALSE  and  a  '1'  represents  TRUE. 


Initial  state 

Datagram  to  send 

OR  to  send  datagram 

Send  the  datagram 

Reset  the  flags  after 
sending  datagram 

Datagram  receive  request 

OR  to  receive  datagram 

Receive  datagram 

Reset  flags  after 
receiving  datagram 


Figure  4-9.  UMLD  TR/TA  Allowable  States. 


;,'ot3  that  the  mechanism  starts  in  the  all  zero,  or  FALSE,  state 
with  no  datagrams  to  send  or  receive  and  returns  to  the  all  sero  state 


at  the  completion  of  sending  or  receiving  a  datagram.  Also,  only  one 


process  of  sanding  a  datagram  or  receiving  a  datagram  is  allowed  at  one 
time . 

If  the  handshake  Is  present,  then  the  boolean  flags  may  only  be  in 
certain  states  before  sending  the  datagram,  l.e.,  the  UMID  cannot 
transmit  if  it  is  receiving  a  datagram  from  the  host  and  it  cannot 
receive  a  datagram  if  it  is  transmitting  a  datagram  to  the  host. 
Appendix  F  explains  the  use  of  the  software  handshake  used  in  the  MET03 
and  in  conjunction  with  iIMIQ  ll  testing. 

Mote  in  Figure  4-7  that  the  interrupts  are  disabled  before  masking 
"off"  or  "on"  of  a  particular  interrupt  bit.  The  interrupts  must  be 
disabled  before  changing  the  interrupt  mask  as  It  is  possible  that  an 
Interrupt  could  occur  which  would  change  the  interrupt  mask  during  the 
time  that  the  interrupt  mask  is  being  changed  in  the  route! ou: 
procedure.  Since  the  interrupt  mask  could  be  changed  by  an  Interrupt 
procedure  while  another  process  is  attempting  to  change  the  mask,  the 
later  process  Ls  then  a  critical  region  and  must  ce  protected  before  any 
manipulations  of  the  interrupt  mask  occur  (13:73).  Further  discussion 
of  critical  regions  .nay  be  found  in  Appendix  E  and  (13). 

The  companion  procedures  that  communicate  with  the  coutsjout 
procedure  using  the  software  handshake  are  the  transmit  and  receive 
interrupt  procedures.  Each  of  these  procedures  must  be  capable  of 
sending  and  receiving  datagrams  correctly  depending  on  the  particular 
state  of  the  IX/ FA  Boolean  states.  The  procedures  must,  In  addition,  be 
capable  of  transmitting  and  receiving  datagrams  from  a  nost  that  does 
not  require  the  R/ CA  handshake.  The  plain  language  pseudo  code  for  the 
receive  interrupt  is  shown  In  Figure  4-13  and  the  for  the  transmit 
Interrupt  is  shown  in  Figure  4—11.  Note  that  the  code,  along  with  the 


code  of  the  route$out  procedure  La  figure  4-7,  implements  the  logic  of 
the  tour  boolean  variables  Ln  tho  truth  table  in  Figure  4-9. 

if  ((not  trta)  or  ((rxtr  and  txta)  and  ((not  txtr)  and 
(not  rxta))))  then 
do 

put  received  character  Ln  next  empty  buffer  space 
Increment  received  character  count 
increment  receive  buffer  Lndex 

If  received  character  count  >=  datagram  size  then 
do 

adjust  pointer  to  next  datagram  area 
if  receive  buffer  index  >=  max  index  then 
reset  index 

reset  receive  character  count 
resat  rxtr  false 
reset  txta  false 
reset  send  false 
end 

end 

If  trta  then 
do 

If  receive  character  -  transmit  acknowledge  then 

If  ((txcr  and  (not  cxta))  and  ((not  rxtr)  and 
(not  txta)))  then 
do 

set  rxta  true 
reset  send  false 
end 

It  receive  character  =  transmit  request  then 

if  (((not  rxtr)  and  (not  txta))  and  ((not  txtr)  and 
(not  rxta)))  then 
do 

set  rxtr  true 
set  txta  true 
set  send  true 
send  ta  to  host 
end 

end 

cleac  interrupt 

Figure  4-10.  kecalve  interrupt  Procedure 


The  implementation  of  the  four  boolenn  variables  guarantees  that 
oftware  will  be  executed  exactly  according  to  the  Logic  in  tile 


truth  table.  dote  also  that  the  routine  counts  the  number  o£  bytes 
received  and  Increments  the  Index  In  the  buffers.  When  a  full  datagram 
is  received,  then  the  pointers  and  rk/TA  variables  are  adjusted  for  the 
next  datagram  reception.  Che  variable  send  Is  used  to  guarantee  that 
the  software  does  not  attempt  to  send  a  datagram  when  transmission  of  a 
datagram  has  already  begun.  This  prevents  the  UNID  from  attempting  to 
send  the  same  datagram  more  than  once  before  a  slow  host  can  raspond  to 
the  InLtlal  datagram  transmission. 

| - 1 

i.f  ((not  trta)  or  ((txtr  and  rxta)  and  ((not  rxtr)  and  i 

'  (not  txta))))  then 

do 

send  next  character  to  host 
increment  transmi tted  character  count 
Increment  transmit  buffer  index 
if  number  bytes  sent  >=  datagram  size  then 
do 

j  mask  transmit  Interrupt  bit  off  j 

reset  transmitted  character  count 

if  transmit  buffer  Lndex  >-  max  index  then  j 

reset  I 

j  ceset  txtr  false 

reset  rxta  false 
reset  send  false 

end  | 

end 

clear  Interrupt 

l _ _ 

Figure  4—11.  Transmit  Interrupt  Procedure 

'JNID  II  Data  Link  Layer  S of  tware  Design 

fhe  basic  design  of  this  software  nodule  follows  the  DELNEf 
require nents  elaborated  upon  in  Chapter  Two.  The  CCLfT  T.23  LAPB 
standard  (23)  was  Inplemented  in  previous  work  (29,  32,  75)  with  one 
variation  which  was  retained  In  tnls  work.  The  variation  relates  to  the 


number  of  unacknowledged  frames  the  data  l  lyer  link  software  will  aLlow 


bafore  retransmitting  Che  next  fraue  to  send.  The  LAPB  standard  allows 
three  bits,  or  eight  [rimes,  for  use  with  Its  sliding  window  protocol 
(37:148-153).  The  Implementations  In  the  previous  work  use  only  one 
bit  and  allow  only  one  unacknowledged  frame  oafora  retransmission  In 
order  to  gain  a  uinlmally  working  software  module  that  passes  frames 
correctly  (29,  32,  73).  the  use  of  one  bit  in  this  protocol  is  known  as 
i  one  bit  sliding  window  protocol  (37:151).  This  'work  follows  previous 
work  and  uses  only  one  bit  and  one  unacknowledged  frame  before 
retransmission.  As  in  the  network  layer,  communications  between  layers 
is  accomplished  through  the  header  information,  in  this  case  with  the 
packet  header. 

The  basic  funccion  of  the  data  link  layer  is  to  accept  frames  from 
the  network  and  route  them  either  to  the  network  layer  or  to  another 
'MID  in  the  network  and  accept  packets  from  the  network  layer  and  route 
the  n  to  the  network.  sequencing  and  flow  control  between  UN  IDs  in  the 
network  Is  done  at  this  layer.  Figure  i  In  Appendix  A  Is  the 
ippLlcaoie  DfD  for  this  level  of  implementation.  The  data  dictionary  In 
Appendix  'j  and  the  compiled  Listings  in  Appendix  II  contain  the  detailed 
implementation  of  this  software  module. 

Figure  4-L2  represents  a  primitive  structure  chart  showing  the  high 
level  structure  of  the  data  LLnx  layer  software.  Packets  and  frames  are 


jroute$in' 


route?out 


Figure  4-12.  Data  Link  Layer  High  Level  Structure  Chart 

Figure  4-13  shows  the  structure  chart  representation  tor  the 
route$in  procedure.  The  "do'-'end'  construct  is  taken  directly  froa  the 
PL /A  Language  to  explicitly  delineate  a  specific  Dlock  of  code.  The 
construct  functions  exactly  as  the  'begin'-'end'  construct  in  Pascal. 
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Fiauce  4-13.  loutejln  Procedure  Structure  Chart 


frame  has  been  received  frotn  network  then 
do 

if  the  trains  Is  a  supervisory  frame  then 
do 

if  tiie  sequence  bit  is  true  then 
do 

set  this  sequence  bit  true 

if  tnis  sequence  bit  equals  transmitted  sequence  bit 
then  do 

toggLe  tiie  transmit  sequence  bit 
initialize  the  acknowledge  variables 
end 

e  ad 

else 

do 

set  this  sequence  bit  false 

If  this  sequence  bit  equals  transmitted  sequence  bit 
then  do 

toggle  the  transmit  sequence  bit 
Initialize  the  acknowledge  variables 
end 

end 

end 

else  {  frame  Is  an  information  frame  } 

do 

determine  destination  of  information  frame 
if  destination  is  network  to  network  then 
do 

if  frame  sequence  bit  is  true  then 
sat  input  sequence  bit  true 

else 

set  input  sequence  bit  false 
build  a  supervisory  frame 
nova  frame  to  transmit  buffer 
service  transmit  buffer  pointer 

end 

if  destination  Is  network  to  local  then 
io 

if  frame  sequence  bit  is  true  then 
set  Input  sequence  bit  true 

else 

set  input  sequence  bit  false 
build  a  supervisory  frame 
move  frame  to  Local  buffer 
servLce  local  buffer  pointer 
end 

end 

end 

service  receive  buffer  pointer 


Figure  4-14. 


koute.Jin  Procedure  Pseudocode  (Part  L) 


> 

Figures  4-14  and  4-15  elaborate  the  route$in  procedure  In  plain 

j  language  pseudocode.  Figure  4-14  represents  the  software  for  one  of  the 

two  UNID  II  data  channels  communicating  with  the  rest  of  the  network. 

Only  one  set  of  channel  software  Is  shown  here  for  clarity. 

|  In  Figure  4-14,  the  software  determines  if  a  frame  Is  In  the 

receive  buffer.  When  a  frame  is  received,  the  frame  header  Is 

interrogated  to  determine  if  the  frame  is  an  information  frame  or  a 

supervisory  frame.  4  received  supervisory  frame  is,  in  this  software 

implementation,  an  acknowledgement  from  the  next  UNID  that  an 

information  frame  has  been  received  correctly  from  this  UNID.  Other 

supervisory  information  may  be  coded  in  the  frame  header  however  these 
i 

features  were  not  implemented  in  the  current  work.  A  received 
Information  frame  Is  data  from  another  UNID  destined  for  another  UNID  or 
.  _  a  host  attached  to  this  UNID.  The  supervisory  and  information  frames 

I  I  • 

must  be  detected  first  before  the  destination  of  the  frame  in  order  to 
correctly  determine  the  disposition  of  the  received  frame.  An 
information  frame  is  not  intended  to  be  sent  to  the  host  attached  to  the 

I 

UNID.  Che  sequence  olt  is  interrogated  to  determine  its  state.  If  the 
received  sequence  bit  is  the  same  state  as  the  expected  received 
sequence  bit,  the  information  frame  received  at  the  distant  UNID  was 
received  correctly  and  in  order  as  denoted  by  the  matching  sequence 
bits.  if  the  sequence  bits  do  not  match,  then  an  error  has  occurred  in 
the  transmitted  information  frame  or  the  received  supervisory  frame  and 
this  UNID  will  retransmit  the  Information  frame  to  the  distant  UNID. 
When  the  received  supervisory  frame  matches  the  expected  supervisory 
frame,  the  sequence  bit  Ls  toggLed  to  its  next  state  and  the  acknowledge 


variables  are  reinitialised. 


Whan  in  Information  frame  Ls  received,  its  header  is  Interrogated 


for  its  destination  and  the  received  sequence  bit.  The  received 

I 

information  frame  may  go  to  another  UN£D  or  to  an  attached  host.  In 

either  case,  a  supervisory  frame  is  generated  to  the  sender  using  the 

j  sequence  bit  received  in  the  information  frame  header  and  the  frame  is 

moved  to  the  next  buffer.  Note  that  the  UMID  is  not  responsible  for  end 

to  end  sequencing;  the  UMID  is  only  responsible  for  UMID  to  UNID 

sequencing.  If  the  sender  did  not  receive  the  acknow ledge ment  in  the 
I 

supervisory  frame  correctly,  it  will  resend  the  same  information  frame 

and  the  UMID  will  acknowledge  accordingly  and  move  the  received 

Information.  It  is  the  responsibility  of  the  transport  layer  software 
i 

to  insure  that  sequencing  of  the  information  is  correct  from  the  network 
before  passing  information  to  the  attached  host.  Notice  that  if  the 
.  .  .  received  frame  header  is  corrupted  and  the  software  cannot  determine  if 

I  *• 

the  frame  is  a  supervisory  or  information  frame,  the  buffer  pointer  Ls 
adjusted  for  the  next  frame  and  the  frame  just  received  is  effectively 
destroyed.  This  type  of  interrogation  keeps  corrupted  frames  from  being 
sent  throughout  the  network  ind  to  the  hosts. 

Figure  4-L5  is  the  plain  language  pseudocode  for  the  second  part  of 


the  route.?in  procedure. 


If  packet  has  been  received  from  network  layer  then 
do 

determine  network,  destination 
if  destination  for  channel  1  then 
do 

determine  if  information  in  transmit  buffer  1 
if  no  info  frame  in  transmit  buffer  then 
do 

build  an  information  frame 
service  local  buffer  pointer 
and 

end 

if  destination  for  channel  2  then 
do 

determine  if  information  in  transmit  buffer  2 
if  no  Info  frame  in  transmit  buffer  then 
do 

buiid  an  information  frame 
service  local  buffer  pointer 
end 

end 

end 


Figure  4-13.  Toute$ln  Procedure  Pseudocode  (Part  2) 


This  section  of  software  determines  if  a  packet  has  been  received 
coc  transmission  into  the  network.  The  packet  header  is  interrogated  to 
determine  its  destination.  The  network  transmit  buffer  J  s  then 
interrogated  to  determine  if  an  unacknowledged  information  frame  is  in 
the  buffer  destined  for  another  UNIO.  If  an  unacknowledged  information 
frame  is  in  the  network  transmit  buffer,  then  the  packet  is  not  iiov-ed 
into  the  network  transmit  buffer.  It  will  be  left  untouched  where  It  is 
until  the  software  reinterrogates  the  local  to  network  buffer.  If  the 
network  transmit  buffer  does  not  contain  an  unacknowledged  information 
frame,  than  the  software  builds  an  information  frame  and  moves  the 
packet  and  frame  header  into  the  network  transmit  buffer  awaiting 
transmission  to  another  UNIO.  Touting  determination  to  either  channel  one 
or  two  Is  simply  determined  by  the  shortest  pith  to  the  destination 
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UMtD.  The  coating  calculation  Is  very  simple  based  upon  the  fact  that 
the  IJNID  network  architecture  Is  a  bi-directional  ring. 

During  the  review  of  the  data  link  layer  software  from  previous 
■work,  several  implementation  errors  were  detected.  For  example,  the 
received  frames  from  another  UNID  were  first  interrogated  for  their 
•destination  rather  than  their  information  or  supervisory  function.  This 
error  caused  supervisory  frames  to  be  generated  for  received  supervisory 
frames.  Since  the  supervisory  frames  would  be  acknowledged  at  both 
UMIDs  ad  infinitum,  the  network  would  quickly  become  overloaded  with 
supervisory  frames  and  the  network  would  cease  to  function.  This  error 
and  others  are  discussed  In  more  detail  In  Appendix  B. 

L? N 1 0  II  Software  Development  Tools 

To  develop  the  UtflD  II  software  in  a  reasonable  length  of  time, 
certain  software  tools  were  developed.  The  tools  were  used  mainly  in 
the  testing  area  and  are  discussed  here  as  they  relate  to  the  overall 
software  design  of  the  UNID  II  software  development.  Detailed 
descriptions  and  use  of  these  tools  are  discussed  in  Chapter  Five  and 
complete  listings  are  In  Appendix  H. 

Software  was  developed  on  the  host  Intel  System  III  to  simulate 
both  the  network  and  data  link  layer  software.  Each  of  these 
simulations  allowed  the  operation  and  validation  of  the  UNID  II  software 
on  the  software  development  system  where  it  was  relatively  easy  to  make 
software  changes  In  order  to  correct  errors  In  design  and 
Implementation.  The  main  thrust  of  this  development  was  to  use  the 
proposed  operational  software  with  the  ability  to  insert  test  datagrams 
Into  receive  buffers  to  simulate  the  reception  of  a  datagram  from  a 


host.  fhe  software  lias  a  software  loop  from  the  transmLt  side  back  to 
the  cecelve  buffer  to  show  the  simulation  of  the  action  and  response  of 
the  network.  The  datagrams,  packets  and  frames  were  observed  to  be  in 
certain  buffers  at  certain  points  in  the  program  execution,  thereby 
validating  the  fact  that  tne  datagram,  packets  and  frames  were  correctly 
routed.  The  caceived  datagram,  packet  and  frame  were  displayed  on  the 
development  systen  to  confirm  that  the  data  entity  did,  in  fact,  return 
to  It's  origin.  Figure  4-16,  simLLar  to  Figure  4-2,  shows  the  the  data 
structure  and  flow  used  for  the  network  layer  simulation.  The  indexed 
array  names,  pointer  nanes  and  senaphore  names  are  Identical  with  those 
use!  In  Figure  4-2. 
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Figure  4-13.  UN1D  II  Network  Link  Layer  Simulation 
Data  Structures  and  Flow 


Figure  4-17,  similar  to  Figure  4-1,  shows  the  data  structure  and 
flow  used  for  the  data  link  layer  slmlulatlon.  The  indexed  array  names 
and  pointer  names  are  identical  with  those  used  in  Figure  4-1. 


The  development  system  host  operating  system  calls  ware  used  for 
the  operator  Interaction  and  console  I/O  required  of  the  simulation. 
This  method  saved  the  time  and  effort  of  programming  EPROMs  and 
attempting  software  validation  on  the  target  hardware  SBC.  Once  the 
software  was  validated  to  show  that  it  did,  indeed,  route  datagrams, 
packets  and  frames  correctly,  it  was  transferred  to  EPROMs  and  installed 
on  the  target  SBC  wLth  the  appropriate  hardware  initialization 
procedures . 

Another  software  program  was  developed  on  the  System  III  for  use  on 
a  host  processor  system  to  transmit  and  receive  datagrams  between  the 
host  and  the  rJNlO  II  at  the  network  layer.  The  host  used  for  the  SBC  544 
Interface  was  the  a  CP/M  30  system.  This  host  was  chosen  because  the 
simulation  software  on  the  CP/M  system  could  be  easily  developed  In 
PL/M30,  the  software  could  be  debugged  on  the  System  HI  software 
development  system,  the  hardware  Interface  between  the  'JNID  II  and  the 
C?/M  system  existed,  and  last  but  not  least,  the  software  would  execute 
on  the  CP/M  system  with  the  appropriate  Interface  to  the  I/O  and 


operating  system.  This  method  was  used  with  the  SBC  544  board  and  could 
be  used  with  the  SBC  33/45  board  simulating  the  UN I 0  to  IJMID  Interface. 
This  software  validation  method  and  system  were  essential  to  further  the 
validation  of  the  UMI!)  LI  software.  The  U N I D  LI  software  could  then  be 
excerctsed  In  a  more  realistic  operational  environment  where  the  errors 
of  design  oversight  and  real  time  operation  could  be  excerclsed. 

\  monitor  program  for  the  SBC  544  was  developed  froa  a  monitor 
available  for  the  S3C  36/124  board.  The  monitor  was  Installed  In  EPROM 
and  proved  invaluable  in  the  initial  checkout  and  functional  operation 
of  the  SBC  544  board.  The  paper  tape  read  and  write  functions  were 
deleted  as  these  functions  were  not  needed  for  the  SBC  544.  The  display 
of  memory  data  was  modified  to  Include  an  ASCII  display  of  the  memory 
data.  A  fill  a  block  of  memory  with  a  constant  function  was  also  added. 
The  same  monitor  used  for  the  SBC  86/L2A  board  may  also  be  used  for  the 
SBC  33/45  board  with  minor  hardware  Initialization  changes. 

1 J N 1 D  1 1  Sys  tern  Memory  Map 

The  system  memory  nap  Is  Important  because  it  Is  necessary  to 
insure  that  the  tables,  pointers  and  semaphores  common  to  both  the  SBC 
544  and  SBC  33/45  boards  are  correctly  positioned  and  known  to  the 
network  and  data  11 nx  layer  software  executing  on  each  board.  Each 
board  has  Its  own  RAM,  part  of  which  is  capable  of  being  napped  into 
what  Intel  calls  the  system  memory.  System  memory  is  that  memory,  with 
Its  own  local  board  address,  that  Is  physically  resident  on  a  given  SBC 
which  is  also  mapped  onto  the  multibus  Lntectace  as  memory  available  to 
any  SBC  on  the  same  multibus.  The  memory  address  mapping  on  the 
multibus  Is  the  address  that  that  section  of  RAM  occupLes  in  the  system 
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memory.  When  a  processor  writes  into  a  section  of  local  memory  which  is 


also  mapped  into  the  system  memory,  the  data  which  is  written  is  also 
changed  at  the  corresponding  mapped  address  in  the  system  memory.  When 
a  processor  reads  from  a  section  of  local  memory  which  is  also  mapped 
into  the  system  memory,  the  data  which  is  read  reflects  the  data  in  the 
Locations  from  the  corresponding  mapped  address  in  the  system  memory. 

The  system  memory  map  used  for  the  U-MIi)  II  is  depicted  in  Figure  4- 
13.  \1L  addresses  are  shown  in  the  hexideclmal  number  base  (hex).  Note 
that  the  SBC  344  only  has  an  addressing  space  of  0  -  FFFF  hex  whLle  the 
system  memory  and  SBC  33/45  have  address  spaces  of  3  -  FFFF?  hex. 
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The  common  tables,  pointers  and  semaphores  are  In  system  memory 
between  L0000  and  llrFF  hex.  The  SBC  544  can  map  1000,  2000  or  4000  hex 
of  Its  available  4000  hex  memory  onto  the  multibus  at  even  1000  hex 
boundaries  (47),  but  only  2000  hex  Is  required  to  be  napped  Into 
systam  namory  to  accommodate  the  common  tables,  pointers  and  semaphores. 
The  physical  RAM  for  the  common  software  parameters  is  on  the  SBC  544 
ooird  and  must  be  there  because  the  3035  processor  space  on  the  board 
cannot  reach  to  the  10000  hex  and  above  addresses  and  therefore  cannot 
read  or  write  above  FFFF  hex.  The  above  memory  mapping  is  also  useful 
during  the  testing  phase  as  it  allows  another  SBC  to  view  the  SBC  544 
memory  contents.  This  feature  Is  explained  in  more  detail  in  Chapters 
F l ve  and  Si x. 

The  SBC  33/45  board,  however,  can  reach  the  entire  system  memory 
span  as  Its  host  processor  is  the  8083.  This  arrangement  allows  access 
to  shared  system  memory  by  both  boards.  The  SBC  88/45  board  can  map 
either  J000  hex  or  none  of  its  available  4000  hex  memory  into  system 
me  nary,  'io  SBC  33/45  board  memory  is  mapped  into  system  memory  for  this 
design.  fhe  SBC  83/45  board  memory  could  be  mapped  into  any  section  of 
system  a? nory  not  otherwise  used  by  another  board  on  the  multibus.  It 
is  recommended  by  tnis  author  that  any  SBC  33/45  board  memory  mapping  be 
above  10000  hex.  This  allows  another  SBC,  such  as  the  SBC  86/12A  or 
36/30,  to  view  tha  memory  of  the  SBC  33/45.  This  feature  is  extrenly 
useful  for  troubleshooting  problems  during  the  testing  phase,  as  further 
explained  in  Chapters  Five  and  Six. 

The  2PAOM  for  the  SBC  544  resides  in  the  local  memory  at  0  -  1FFF 
hex.  The  2000  hex  size  is  the  maximum  for  that  board  using  two  2  7  3  2  A 


RPROMs.  The  RPRO'f  for  the  SBC  33/45  board  is  at  FC000  -  FFFrF  hex.  The 


4000  hex  size,  wnlle  not  the  maximum  of  0000  hex,  Is  adequate  for  this 
application.  The  board  uses  four  2764  EPROMs. 

Conclusion 

This  chapter  discussed  the  detailed  design  and  Implementation  of 
the  UNID  11  software.  The  discussion  was  divided  into  six  sections  which 
Included:  Development  Language  Selection;  UNID  II  Data  Structures;  UNID 
1 1  Network  Layer  Software  Design;  UNIO  [I  Data  Link  Layer  Software 


Design;  UNIO  II  Software  Development  Tools;  and  UNID  II  System  Memory 
Map.  Chapter  Five  discusses  the  UNID  LI  testing  philosophy  and  design. 


7 .  fes  t  Philosophy  and  Design 


Introduc  tlon 

This  chapter  outlines  the  test  philosophy  and  design  of  the  UNID  II 
software  and  hardware  developed  In  this  research  and  development  effort. 
The  basic  test  philosophy  is  discussed  first,  followed  by  a  description 
of  the  overall  test  design.  The  major  diagnostic  test  tools  used  for 
testing  are  then  discussed  followed  by  a  description  of  each  of  the 
testing  phases.  TestLng  results  are  Included  In  the  discussion  of  each 
phase  of  tesclng. 

Test  Philosophy 

The  overall  philosophy  of  most  any  test  Is  to  'prove',  by  some 
speciflei  means  and  tools,  that  a  certain  specified  event  does,  does  not 
or  to  some  degree  occurs.  The  word  'prove'  may  take  on  many  meanings  to 
many  people.  While  some  desire  to  see  a  de tailed  mathematical  tretlse 
to  'prave'  a  hypothesis,  others  are  satisified  with  a  note  pragmatic  or 
economic  approach  of  observing  a  demonstration  as  a  means  of  'proof'. 
In  some  definitions,  the  formal  mathematical  proof  is  called 
verification  while  the  more  economic  demonstration  Is  called  validation. 
Validation  also  provides  the  developer  and  user  with  some  Level  of 
confidence  that  the  Item  under  test  functions  as  desired.  This  effort 
uses  the  validation  approach  because  of  the  cheaper  economics  to 
demonstrate  the  system  works  as  described  compared  with  a  detailed 
mathematical  proof  that  the  system  works  as  described. 

While  most  design  efforts  begin  with  1  top-down  approach  to  the 
particular  problem  us  Lag  step- wise  ref Ineaent  techniques  to  finally 


ichleve  u  tractable  solution,  i  considerable  i  a  mint  of  testing  effort 


begins  .it  the  bottom  and  works  Its  way  to  the  top.  The  testing  of  the 
UNID  It  hardware  and  software  takes  the  bottom-up  approach.  The 
approach  follows  that  often  used  with  software  testing,  specifically: 
module  testing,  Integration  testing,  and  overall  systems  tasting.  While 
there  are  many  testing  methodologies,  such  as  static  and  dynamic 
testing,  applied  to  three  phases  of  testing,  the  general  methodology 
used  In  this  effort,  in  following  with  previous  testing  efforts  (75:3- 
l),  will  he  path  testing.  Boundary  condition  testing,  while  important 
In  Its  own  right,  was  not  emphasized  during  the  tasting.  Some  boundary 
testing  ind  provision  for  display  of  the  boundary  violations  is  provided 
In  the  software  design  Itself  and  available  to  the  tester. 

Overall  Tes_t  Design 

Since  the  ultimate  goal  of  the  UNID  il  is  to  provide  the 
communications  media  for  host  computec  systems,  the  testing  is  oriented 
towards  the  validation  of  nost-to-host  communications  through  the  UNID. 
To  that  end,  UNID  ll  testing  was  divided  Into  five  phases.  The  testing 
began  at  the  lower  level  software  modules  and  progressed  to  the  larger 
programs  which  Integrated  the  lower  level  modules.  Both  of  these  phases 
used  the  Intel  System  III  and  simulation  as  the  test  venicle.  The 
third  phase  was  involved  with  the  interface  and  preliminary  system  test 
of  the  SBC  544  with  a  simulated  host  on  a  CP/d  system.  This  phase 
Involved  the  use  of  the  operational  software  on  the  SBC  544  and 
simulation  software  on  the  CP/M  host.  The  fourth  phase  was  a  system 
test  of  the  SBC  544  with  the  LSI-ll  NETOS.  The  SBC  544  with  operational 
software,  the  host  CP/M  system,  a  display  terminal,  and  four  of  the 
nodes  In  the  CSI-ll  NEfOS  were  the  test  vehicles.  The  fifth  and  l  a  at 
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phase  was  to  connect  two  or  inore  UNID  IIs  In  their  operational  network 
configuration  and  attach  host  computer  systems  to  the  UNIDs  and  conduct 
host-to-hosc  communications  through  the  UNID  network. 

Only  the  first  four  phases  were  conducted.  The  fifth  phase  was  not 
conducted  because  only  one  UNID  II  was  available  for  development  and 
test.  4s  more  UNID  It  hardware  Is  acquired,  this  last  phase  is  the  next 
logical  step  In  the  development,  test  and  operation  of  the  UNID  II  in 
the  DELNEI. 

Maj or  Diagnos tic  Test  Tools 

While  the  test  philosophy,  design  and  methodology  outline  the  major 
steps  to  determine  If  an  entity  Is  operating  properly,  the  test  tool  is 
the  basic  Instrument  used  to  Implement  the  actual  testing.  Path  testing 
Ls  the  major  methodology  used  in  the  UNID  II  testing  to  determine  if  the 
software  was  operating  properly.  Path  tasting  essentially  shows  that 
the  entity  under  test  follows  a  desired  path  while  traversing  some  media 
from  its  source  to  Its  destination.  To  implement  the  path  testing 
methodology,  three  major  diagnostic  tools  were  developed  and  used. 

The  major  diagnostic  tool  used  for  path  testing  In  this,  and 
previous  work  (64,  75),  Is  to  Insert  diagnostic  messages  at  strategic 
locations  In  che  various  software  modules  to  show  that  a  process  or  the 
data  did,  In  fact,  follow  a  certain  path.  The  diagnostic  messages  are 
typically  displayed  on  a  computer  terminal  attached  to  the  hardware 
under  test  or  at  the  terminal  of  a  development  system,  as  dictated  by 
the  particular  test.  When  a  message  is  displayed  when  It  should  be 
displayed,  the  observer  is  assured  that  the  software  under  test  did,  in 
r  act,  follow  the  desired  path.  If  a  message  Is  displayed  when  It  should 


not  be  displayed,  the  observer  Ls  assured  that  the  software  traversed  an 
Incorrect  path.  If  a  message  Ls  not  displayed  when  It  should  be 
displayed,  the  observer  could  conclude  that  a  problem  exists  In  the 
hardware,  software  or  their  own  perception  of  when  the  message  should  be 
displayed.  The  lack  of  a  displayed  message  Is  not  conclusive  proof  that 
a  problem  exlscs  In  the  software  as  other  conditions  may  exist  to 
prevent  the  display  of  the  message.  The  observer  needs  to  look  further 
at  the  conditions  of  the  test,  or  even  generate  other  tests  or 
diagnostics,  to  determine  If  the  software  Is  at  fault. 

Another  major  diagnostic  tool  used  In  the  UNID  II  testing  was  to 
use  the  monitor  program  on  SBC  36/12A  with  the  S8C  544  to  view  the  data 
tables,  variables,  pointers,  flags  and  semaphores  In  the  S3C  544  memory. 
As  the  reader  will  recall  from  Chapter  Four,  the  memory  of  the  SBC  544 
was  mapped  into  system  memory  for  two  reasons:  to  pass  data,  pointers 
and  semaphores  to  the  SBC  83/45  and  to  allow  an  external  processor  to 
view  the  memory  contents  of  the  SBC  544  during  operation.  This  tool  was 
used  where  It  was  not  feasible  to  insert  diagnostic  messages,  such  as 
attempting  to  display  the  contents  of  a  large  number  of  variables  or 
data,  as  well  as  to  view  the  memory  contents  during  the  operation  of  the 
UNID  II.  The  ability  to  observe  the  contents  of  the  variables  proved 
to  be  Invaluable  while  attempting  to  trouble  shoot  software  that  did  not 
work  as  designed. 

The  last  major  diagnostic  tool  was  a  CP/d  system  used  to  simulate  a 
host  to  the  UNID  IL.  This  tool's  advantage  hies  with  the  ability  to 
send  and  receive  datagrams  from  the  UNID  t l.  This  ability  allowed  the 
UNID  ll  to  be  tested  in  a  more  real  time  environment  and  provide  a  more 
realistic  test  of  the  UNID  II  software.  IhLs  tool  was  chosen  because  the 
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system  was  readLLy  available  where  others  were  not,  the  simulation 
software  was  relatively  easy  to  develop,  the  3.S-232  hardware  interface 
to  the  UNID  II  existed. 


Phase  One  Testing 

Only  a  few  of  the  low  level  software  modules  from  the  original 
software  (64,  75)  were  tested  on  a  module  basis.  The  tested  modules 
were  related  to  the  display  of  the  diagnostic  path  testing  messages  on 
the  host  operating  system  or  other  display  terminal.  A.  small  print 
program  was  developed  to  validate  the  correct  interface  with  the  ISIS 
operating  system  calls.  Messages  were  typed  at  the  operator  keyboard 
and  then  displayed  on  the  ISIS  terminal.  The  remaining  modules  had  been 
previously  tested  (75:Ch  3,  Ch  5)  and  were  assumed  to  be  correct  with 
the  exception  of  implementation  errors  during  the  software  conversion 
f com  PL /Z  to  PL/M. 

Phase  Ewo  Tes  ting 

A  simulation  capability  was  developed  on  the  software  development 
the  Intel  System  III,  which  allowed  the  development  and  test  of  the 
individual  modules  through  the  fully  Integrated,  single  board  computer 
level  programs.  The  simulation  method  allowed  the  functional  validation 
and  testing  of  the  fully  operational  software  on  the  development  system. 
When  che  validated  software  was  then  installed  on  the  single  board 
computer,  it  was  known  to  correctly  receive,  iterpret  datagram,  packet 
and  frame  headers,  and  coute  the  lata  correctly  since  It  h3d  just  been 
validated  via  simulation  with  a  large  degree  of  confidence  that  the 
software  functioned  properly. 

This  simulation  capability  was  decided  upon  because  it  was 
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'simpler'  and  more  time  efficient  to  test  the  software  functionality 
before  Installing  the  software  on  the  single  board  computers  and  testing 
with  the  ln-clrcult  emulator  (ICE),  the  ICE  86.4,  the  CP/M  system,  or  the 
NET05.  There  was  also  no  ICE  85  (40)  available  for  the  SBC  544  board 
during  the  testing  period.  In  addition,  the  ICE  is  used  mainly  for  new 
designs  where  the  hardware  Is  designed  and  developed  from  scratch  and 
does  not  use  off  the  shelf  single  board  computers.  The  simulation 
capability  allowed  the  testing  of  software  modules  where  incorrect 
software  functioning  could  be  readily  detected  and  corrected  without  the 
necessity  of  executing  the  unproved  software  on  the  target  hardware 
system.  Experience  with  the  systems  showed  that  software  changes  could 
be  readily  made,  the  program  recompiled  and  retested  in  approximately  10 
to  20  minutes  where  similar  changes  for  the  target  hardware  required  30 
or  more  minutes  to  complete. 

The  interface  of  the  programs  with  the  System  III  required  the  use 
of  the  ISIS  operating  system  calls  for  message  display  and  opecator 
keyboard  interaction.  Appropriate  software  procedures  were  developed  to 
insert  datagrams  and  packets  in  the  buffers  of  the  operating  software 
and  to  display  the  contents  of  the  buffers.  Figures  5-1  and  5-2  show 
the  operating  software  data  flow  and  the  software  loops.  The  labels  are 
the  same  used  for  Figures  4-1  and  4-2. 

In  Figure  5-1,  datagrams  were  Inserted  in  the  LC01.3X  receive  buffer 
with  operator  options  allowing  the  choice  of  destination  3nd  number  of 
datagrams.  The  destination  was  chosen  by  selecting  a  UNIO  number.  The 
operator  then  had  the  option  of  choosing  the  destination  port  by 
selecting  a  host  code  between  0  and  2  >5.  The  network  layer  software 
then  routed  the  datagram  through  the  tibles  and  displayed  the  received 


datagram  on  the  simulation  terminal.  Test  point  messages  displayed  to 
the  System  III  terminal  were  embedded  In  the  software  In  each  procedure, 
and  In  some  cases,  within  t'ne  If-then-else  and  case  statements  to 
validate  the  execution  of  a  particular  section  of  code. 


~Lptr  — > 

Ready  — > 
Done  < — 

~Nptr  < — 

Done  — > 
Ready  <, — 


LPOINTER 
—  _ 

I  LSEM 


npointer; 

(  NS  EM 


— >  “Lptr 

— >  Ready 
< —  Done 

<—  *Sptr 

— >  Done 
< —  Ready 


D 4  r  AGRA i  DAT  AG  RAM/ PACK  £T / FRAME 

123  BYTES  128/ 133/ 135  3YTES 


! 

i 

I 


FRAME 
135  BYTES 


TRANSPORT  NETWORK 

LAYER  LAYER 


DATA  LINK 
LAYER 


Figure  5-1.  Network  Layer  Simulation  Data  Structure  and  Flow 


The  test  datagrams  were  simple  messages  with  a  modulo  10  datagram 
counter  Imbedded  in  the  datagram.  Test  messages  were  inserted  at  certain 
locations  where  an  out  of  range  error  would  occur  to  advise  the  operator 
that  an  error  had  occurred.  This  is  an  example  where  boundary  testing 
was  designed  into  the  path  testing  messages.  The  IP  header  was  also 
displayed  for  troubleshooting  and  validating  that  the  software  did 
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manipulate  the  header  as  and  when  It  should.  A  software  loop  from  the 
transmit  tables  to  the  receive  tables  simulated  communication  with 


another  UNID  through  the  data  link  layer  and  DELNET.  Datagrams  were 
inserted  In  each  of  the  four  receive  buffers  with  each  of  the  transmit 
buffers  as  their  destination.  This  test  was  successfully  accomplished 
both  In  the  local-to-local  host  communication  and  local-to-dis tant  host 
communication  modes. 

The  same  type  of  testing  was  used  with  the  data  link  layer  software 
shown  In  Figure  5-2. 
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Figure  5-2.  Data  Link  Layer  Simulation  Data  Structure  and  Flow. 


Packets  were  inserted  in  the  LCNTTB  buffer  with  operator  selected 
destinations  and  number  of  packets  to  send.  The  receive  test  packets 
were  read  from  the  NTLCTB  and  displayed  with  their  modulo  10  counter  to 
the  operator  on  the  System  III  terminal.  In  this  test,  the  test 
messages  were  also  inserted  in  various  strategic  locations  in  the 
software  as  with  the  network  layer  software.  Test  messages  were  also 
inserted  at  certain  locations  where  an  out  of  range  error  would  occur  to 
advise  the  operator  that  an  error  had  occurred.  This  is  another  example 


where  boundary  testing  was  designed  Into  the  path  testing  messages.  The 
packet  and  t'rame  headers  were  not  displayed  as  there  was  no  need  to  do 
so.  The  test  messages  showing  the  flow  of  the  datagram  sufficed  to 
validate  the  software.  A  software  loop  from  the  transmit  tables  to  the 
receive  tables  simulated  communication  with  other  UNIDs  through  the 
DELMET.  This  test  was  successfully  accomplished  through  all  the 
tables . 

The  simulations  on  the  System  III  were  conducted  with  the  actual 
operational  software  that  would  execute  on  the  SBC  544  and  SBC  88/45 
single  board  computers.  As  errors  were  found  in  the  design  or  logic  of 
the  original  software,  appropriate  modules  were  corrected  or  rewritten 
and  tested  both  on  a  module  by  module  and  overall  program  basis.  The 
implementation  errors  from  previous  work  are  discussed  in  Appendix  C. 

Phase  Three  Testing 

Phase  three  testing  consisted  of  testing  the  network  layer  software 
on  the  SBC  544  with  a  simulated  host  on  a  CP/M  system.  As  previously 
mentioned,  the  data  link  layer  software  W3S  not  tested  on  its  host  SBC 
88/45.  The  simulation  software  was  modified  to  delete  the  ISIS 
operating  system  calls,  Install  the  procedure  that  displayed  massages  on 
an  Heath  H 1 9  terminal  attached  to  the  SBC  544,  and  install  the 
proceduras  to  initialize  the  special  purpose  large  scale  integrated 
circuits  on  the  SBC  544.  Once  these  steps  were  accomplished,  the 
software  was  complied  and  programmed  into  EPROMs  for  the  SBC  544. 
Programming  the  EPROMs  involved  the  use  of  one  of  two  EPROM  programmers 
for  the  two  different  EPROMs  used.  An  Intel  EPROM  programmer  (60)  was 


attached  to  a  second  Intel  system,  a  System  210.  A  software  program  on 


the  System  210  was  used  to  program  2716  EPROMs.  A  Bytek  EPROM 
programmer  (8)  was  attached  to  the  CP/M  system  to  program  2732A  EPROMs. 
A  communications  program  on  the  CP/M  system  downloaded  the  software  to 
the  intellegent  programmer  to  program  the  2732A  EPROMs.  Software 
transportability  between  the  System  III  and  the  System  210  was 
accomplished  with  single  sided,  single  density  ISIS  formated  diskettes. 
Both  Intel  systems  can  read  and  write  single  sided,  single  density 
diskettes.  The  above  procedures  were  developed  for  this  test  as  there 
ware  no  prior  established  procedures. 

Two  different  size  EPROMs  were  used  because  the  initial  testing  in 
this  phase  used  only  one  receive  and  one  transmit  table  for  the  network 
layer  software  and  did  not  require  a  large  amount  of  memory,  the 
interrupt  handling  procedures  for  the  SBC  544  needed  to  be  developed  and 
tested,  and  the  2716  EPROM  programmer  was  directly  available.  This 
approach  was  taken  until  the  Interrupt  handling  procedures  worked 
properly.  In  addition,  the  appropriate  compiler  constructs  for  the  PL/M 
compiler  needed  to  be  validated  in  order  to  correctly  locate  the  ceceive 
and  transmit  tables  in  the  SBC  544  memory.  Then  the  software  was 
expanded  to  its  full  size,  compiled  and  installed  in  the  2732A  EPROMs. 

Transporting  the  software  from  the  System  III  to  the  CP/M  system 
required  an  intermediate  translation  process  on  the  System  210  as  the 
software  was  on  an  ISIS  formatted  diskette  on  the  System  III  and  needed 
to  be  in  a  standard  CP/M  format  for  the  CP//M  system.  A  commercially 
available  program,  procured  by  a  previous  researcher  (64),  was  available 
to  run  on  the  System  210  under  the  CP/M  operating  system.  The  program 
Is  a  file  format  translation  program  which  converts  files  from  ISIS  to 
CP/ il  or  CP/M  to  ISIS  formatted  diskettes.  After  the  network  layec 
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software  was  translated,  It  was  then  downloaded  to  the  EPROM  programmer 
from  the  CP/M  system.  The  EPROMs  were  then  Installed  on  the  SBC  544  and 
the  program  executed. 

The  simulated  host  software  that  executed  on  the  CP/M  system  was 
also  developed  on  the  System  III.  The  software  was  translated  on  the 
System  210  as  explained  above  and  transported  to  the  CP/M  system  where 
It  was  executed.  The  software  used  many  of  the  procedures  already 
developed  for  the  network  and  data  link  layer  simulations.  The 
additional  software  required  consisted  of  interfacing  the  operator  query 
and  response  to  the  CP/M  console  through  CP/M  operating  system  calls. 
The  serial  communication  interface  between  the  SBC  544  and  the  CP/M 
system  was  a  standard  RS-232C  cabia  with  USART  I/O  driver  software  on 
the  CP/M  system  provided  by  an  assembly  language  program  for  that 
purpose.  The  assembly  language  program  was  already  available  (Appendix 
1)  and  only  needed  slight  modification  to  interface  with  the  PL/M 
procedure  calling  conventions  and  add  the  CP/M  operating  system  call 
interface  for  the  main  PL/M  program.  The  register  usage  of  the  PL/M 
procedure  calling  conventions  are  identical  to  many  of  the  CP/M 
operating  system  calls  and  allowed  a  smooth  Interface. 

The  simulated  host  software  was  able  to  send  and  receive  up  to  ten 
datagrams  at  one  time  as  specified  by  the  operator.  The  operator  could 
also  specify  the  routing  of  the  datagram  as  in  the  network  layer 
simulation.  The  testing  then  consisted  of  sending  datagrams  from  the 
simulated  host  to  the  38C  544,  observing  the  diagnostic  messages 
displayed  on  the  H19  terminal  and  observing  the  response  from  the 
simulated  host.  When  Incorrect  or  unexpected  software  behavior  occurred, 
the  test  messages  were  used  In  conjunction  with  the  software  listings  to 
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trace  the  flow  of  the  program  through  Its  execution.  In  addition,  the 
use  of  the  SBC  86/12A  and  Its  monitor  were  used  to  observe  table, 
counter  and  boolean  flag  contents  to  aid  the  determination  of  where  the 
software  was  not  functioning  correctly.  The  H19  was  connected  to  only 
one  port  during  the  test  for  simplicity.  The  RS-232C  cable  was 
connected  sequentially  on  the  three  remaining  ports  and  datagrams  sent 
from  the  simulated  host  to  the  SBC  544  and  returned  on  each  of  the  tnree 
SBC  544  ports.  Both  a  simple  local-to-local  port  loop  and  as  well  as  a 
lccal-to-distant  host  loop  were  tested  successfully  for  all  three  ports. 
The  transmit  reques t/ transml t  acknowledge  handshake,  discussed  in 
Chapter  Four  and  Appendix  F,  was  also  validated.  Figure  5-3,  similar  to 
Figuce  5-1,  shows  the  network  layer  data  flow  and  structures  with  the 
addition  of  the  H19  monitor  and  the  CP/!1  system  used  in  this  phase  of 
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Figure  5-3.  Network.  Layer  Simulation  with  the  CP/M  System  and  dl9 


This  phase  of  testing  W3S  particularly  significant  for  two  reasons. 
First,  both  the  receive  and  transmit  side  of  each  of  the  SBC  544  serial 
ports  are  interrupt  driven.  This  is  significant  because  the  software 
had  to  behave  rationally  while  transmitting  and  receiving  random 
datagrams  on  a  real  time  interrupt  basis  while  'simultaneously'  routing 
datagrams.  Second,  it  was  quickly  discovered  by  observing  incorrectly 
behaving  software  that  certain  sections  of  the  executing  software  needed 
to  be  protected  from  outsLde  interference  while  they  were  executing. 
These  sections  of  code  are  called  critical  regions  (13:77)  and  are 
discussed  In  Chapter  Four  and  Appendix  E.  This  phase  of  tasting  also 
allowed  the  testing  to  occur  under  more  real  conditions  than  the 
simulations  and  demonstrated  the  effects  of  real  time  Interrupt 


programming  and  crLtlcal  regions  that  were  not  possible  during  the 
simulations  on  the  System  1 1  £  development  system. 


Phase  Four  Testing 

This  phase  of  tasting  consisted  of  testing  the  network  layer 
software  from  the  phase  three  testing  on  the  SBC  544  while  the  SBC  544 
was  connected  to  the  LSI-11  NETOS  (72).  Figure  5-4  shows  the  connection 


The  letters  A,  C,  J,  and  K  are  the  designations  for  the  NETOS  nodes 
used  for  this  test.  Each  NETOS  is  a  LSI-11  processor  executing  the 
NETOS  network  software  (72).  The  software  executing  on  the  NETOS  W3S 
developed  as  part  of  a  class  at  the  Air  Force  Institute  of  Technology. 
The  software  implemented  a  half-gateway  (87:Chap  3)  interfacing  the 
NETOS  layer  four  protocol  with  the  UNID  II.  The  UNID  II  half-gateway  is 
Implemented  in  the  network  layer  software  that  Interprets  the  Internet 
Protocol  (IP)  header.  Both  the  NETOS  and  the  UNTO  II  used  the  IP  header 
for  Internet  datagram  routing.  Node  .J  Is  the  central  node  through  which 


all  Che  NETOS  nodes  are  connected  In  a  star  configuration.  Node  C  was 
used  to  Insert  NETOS  messages  Into  the  NETOS  destined  for  the  UNID  II. 
Nodes  A  and  K  were  connected  to  two  of  the  UNID  II  ports  while  the  C?/M 
host  and  the  H19  were  connected  to  the  two  remaining  UNID  ports.  The 
CP/M  host  and  the  H19  terminal  were  used  as  In  the  phase  three  testing 
while  node  C  was  Inserting  NETOS  massages  into  the  NETOS  and  through  the 
UNID. 

Local-to-local  routing  was  tested  where  messages  Inserted  in  the 
NETOS  circulated  clockwise  and  then  counter  clockwise  In  the  ring  A-J-K- 
UNID-A  in  Figure  5-4.  This  test  validated  the  local-to-local  routing 
process  in  the  UNID  network  layer  software.  Other  messages  were 
injected  at  node  C  to  address  another  node  hosted  on  another  UNID.  This 
test  simulated  one  NETOS  node  sending  messages  through  two  UNIDs  to 
another  NETOS  node  and  receiving  replies  by  the  same  path.  In  this 
test,  the  messages  traversed  the  path  C-J-K-UNID-UNID-A-J-C.  The  UNID- 
UNID  designation  represents  the  software  loop  In  the  network  layer 
software.  This  software  loop  remained  in  the  network  layer  software  for 
this  test  as  a  second  UNID  II  was  not  available. 

Messages  were  also  Inserted  at  the  CP/M  system  while  the  NETOS 
nodes  A  and  K  were  sending  and  receiving  messages  with  the  UNID.  This 
test  was  done  to  provide  a  somewhat  higher  message  Loading  on  the  UNID 
to  subjectively  observe  any  detremental  effects.  There  were  no 
detremental  effects  to  the  NETOS  messages  by  the  Insertion  of  additional 
messages  by  the  CP/M  system  during  the  subjective  observation.  This 
phase  of  testing  validated  the  local-to-ne twork  an  ne twork- to- local 
routing  process  in  the  UNID  network  layer  software. 

Of  particular  note  during  this  test  were  Instances  where  the  UNID 


software  'lost'  data  from  the  sending  node.  The  lost  data  was  a  result 
of  the  code  In  the  UNIO  required  to  protect  a  critical  region  and  of  the 
code  in  the  NETOS  which  sent  the  NETOS  messages.  The  NETOS  messages 
were  broken  Into  two  datagrams  which  were  sent  to  the  IJNIO  in  rapid 
succession.  The  UNID  successfully  received  the  first  datagram  from  node 
K  and  while  attempting  to  send  that  datagram  to  node  A,  the  second 
datagram  began  arclvlng  from  node  R.  The  lost  data  occurred  during  the 
reception  of  the  second  datagram  from  node  K.  The  cause  of  the  lost 
data  was  the  result  of  the  disabled  interrupts  required  to  protect  a 
critical  region  in  the  UNID  software.  Data  was  continued  to  be  sent  by 
node  <,  but  while  the  UNID  interrupts  were  disabled  during  transmission 
of  the  first  datagram  to  node  A,  some  of  the  data  from  the  second 
datagram  simply  overflowed  in  the  UNID  USART  and  were  lost.  The  fact 
that  bytes  were  In  fact  being  lost  was  determined  by  using  the  JSC 
86/12A  monitor  to  check  the  program  variables  in  the  S3C  544  r.emory.  lc 
was  juickly  observed  by  checking  the  received  byte  count  that  only  125 
bytes  of  tne  123  byte  datagram  were  received  in  the  SBC  544  memory.  A 
'quick  fix'  patch  was  made  to  the  NETOS  software  to  increase  a  delay 
between  transmission  of  characters  to  the  UNID.  The  patch  was  nude  to 
the  NETOS  software  instead  of  the  UNID  software  as  the  UNID  software  had 
to  be  reinstalled  in  EPROMs  before  retesting.  The  additional 
transmission  delay  between  characters  from  the  NETOS  to  the  UNIO 
alleviated  the  problem  during  the  testing.  The  solution  lies  within  the 
UNID  software  and  has  not  yet  been  established. 

Conclusion 


This  chapter  outlined  the  test  philosophy  and  design  of  the  UNID  ll 
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VI.  Conclusions  and  Recommendations 

Introduction 

The  purpose  of  this  Investigation  was  to  develop  the  UNIO  II  and 
Implement  the  existing  software  designs  to  produce  a  functional  unit. 
Well  over  the  majority  of  the  tasks  In  the  problem  statement  In  Chapter 
One  were  accomplished  as  described  in  Table  VI-I.  The  integration  of 
the  network  layer  and  data  link  layer  software  on  the  SBC  544  and  SBC 
88/45  and  test  and  validation  as  a  functional  U  MID  II  was  not 
accomplished. 


Table  VI-I.  Tasks  Accomplished. 


1.  A  software  monitor  for  the  SBC  544  was  developed. 

2.  The  SBC  86/12A  and  SBC  544  were  Integrated  for  operation 
on  a  multibus  chassis. 

3.  The  functional  operation  of  the  translated  network  layer 
PL/M  software  was  validated  by  simulation  and  test. 

4.  The  Integration,  test  and  validation  of  the  network 
layer  software  hosted  on  the  SBC  544  was  completed. 

5.  The  data  link  layer  PL/Z  software  (75)  was  translated  to 
PL/M  and  validated  for  correct  functional  operation  by 
simulation  on  a  software  development  system. 

6.  The  preliminary  integration,  test  and  validation  of  the 
network  layer  software  and  SBC  544  in  the  DEL  NET  was 
accomplished. 


Conclusions 

The  development  of  the  UNID  II  in  the  DELNET  has  progressed 
considerably.  The  use  of  functional  simulations  on  3  host  software 
development  system  has  enabled  the  developer  to  validate  the  software 
before  installation  and  test  on  the  target  hardware  system.  This 
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capability  can  save  considerable  time  and  effort  attempting  to 
troubleshoot  and  problem  solve  on  a  target  system  by  eliminating  most  of 
the  errors  In  the  software  design  and  code  before  the  software  Is 
executed  on  the  hardware. 

The  Integration  of  the  network  layer  software  hosted  on  the  SBC  544 
with  the  NET03  Is  a  major  milestone  not  achieved  before  this  thesis 
effort.  Two  different  hardware  systems  executing  software  designed  and 
Implemented  by  two  different  groups  of  people  successfully  transferred 
Information.  although  work  remains  to  be  done  to  fully  Implement  the 
UNID  In  the  DELNET,  a  solid  foundation  has  been  developed  which  should 
make  the  task  less  formidable. 

Recommendations 

As  this  Investigation  is  a  continuation  of  previous  research  and 
development,  the  recommendation  by  this  author  is  to  continue  the  UNID 
11  and  DELNET  development.  This  project  has  provided  a  test  bed  for 
some  of  the  practical  experience  required  in  .applying  the  theory  learned 
In  the  classroom.  Specific  examples  from  this  effort  are  the  real  time 
interrupt  programming  and  critical  regions  of  software.  Both  of  the 
examples  are  discussed  in  the  classroom  environment,  however  one  does 
not  gain  the  full  Impact  of  the  theory  and  what  needs  to  be  done  to 
properly  design  the  software,  until  one  actually  designs,  tests  and 
validates  software  of  that  type. 

Not  only  has  this  project  provided  valuable  practical  experience, 
but  the  U.S.  Air  Force  has  a  growing  need  for  a  UNID.  The  Air  Force  and 
other  DoO  departments  are  Incorporating  a  considerable  number  of  single 
and  multiple  user  microprocessor  based  systems  in  the  office 
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environment.  While  many  of  these  systems  have  some  common  media  for 
transferring  Information,  many  do  not.  The  UNID  can  more  than 
adequately  fill  the  gap  In  linking  these  systems  together  to  transfer 
their  Information.  If  for  no  other  reason,  the  UNID  development  should 
continue  to  fill  that  gap. 

Other  specific  recommendations  not  yet  addressed  are: 

1.  The  analysis  of  the  buffer  sizes,  throughput,  delay,  and  host 

and  network  serial  data  rates  has  not  yet  been  accomplished  since  the 
UNID  development  began  Ln  1978.  This  analysis  Is  required  and  must 
eventually  be  accomplished  ln  order  for  the  UNID  to  adequately  support 
the  user  data  traffic.  The  methods  outlined  In  (37:Chap  2,  31,  82) 

could  be  used  as  a  starting  point  for  the  analysis.  This  task  could 
develop  Into  an  entire  thesis  effort. 

2.  Only  the  first  four  of  the  five  test  phases  were  conducted  ln 
this  effort.  The  fifth  test  phase  of  Integrating  the  network  layer  and 
data  link  layer  software  on  the  SBC  544  and  SBC  88/45  and  validating  as 
a  functional  UNID  II  In  the  DELNET  remains  to  be  accomplished.  This 
test  and  validation  can  be  accomplished  as  more  UNID  II  hardware  is 
acqulced.  This  last  phase  Is  the  next  logical  step  in  the  development, 
test  and  operation  of  the  UNID  II  ln  the  DELNET  and  is  required  to  be 
done . 

3.  The  timing  problem  (Chap  Five)  which  arose  during  the  testing 
of  the  UNID  II  and  the  NETOS  needs  to  be  resolved. 

4.  The  data  link  layer  software  needs  to  be  installed  on  the  SBC 
38/45  single  board  computer  and  validated  in  a  network  environment. 

5.  The  further  Implementation  of  the  X.25  network  layer  protocol 
remains  to  be  accomplished,  as  weLl  as  the  Implementation  of  the  higher 
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layer  protocols  for  UNID  host3  computers  aad  the  Internet  protocol  (IP) 
for  networks  connecting  to  the  UNID.  These  Implementations  must  occur 
for  a  functional  DELNET  to  exist. 

6.  Use  the  C  language  for  further  software  development,  especially 

^  In  the  transport  through  the  presentation  layers  of  the  OSI  modal. 

7.  The  DELNET  and  the  supporting  UNIDs  would  comprise  an  excellent 

tool  for  research  and  development  of  user  data  privacy,  user 

authentication,  and  user  'verification'  implementations.  While 
I 

classified  traffic  cannot  be  supported  In  the  APIT  environment,  the 
basic  groundwork  for  a  classified  system  can  be  supported.  The  DoD  has 
a  considerable  interest  in  this  area  (2)  and  much  can  be  gained.  Some 
previous  Investigation  at  AFIT  has  been  started  (86)  with  a  considerable 
amount  in  the  commercial  sector  (5,  10,  14,  15,  65,  79,  83).  (10) 

and  (83)  provide  Introductory  material  while  (5,  14,  15,  65,  79) 

i  (• 

provide  more  advanced  material.  Research  and  development  in  these  areas 
can  easily  encompass  several  theses. 

Concluding  Remarks 

A  considerable  amount  of  time,  effort  and  resources  have  been 
applied  to  the  design,  Implementation  and  testing  of  the  UNID  and  the 
DELNET.  There  is,  however,  still  much  work  to  be  done  before  the  UNIDs 
can  perform  in  a  local  area  network  function.  It  is  this  author's 
opinion  that  this  project  is  valuable  and  can  pay  large  dividends,  both 
to  satisfy  U.S.  Air  Force  operational  needs  and  as  a  learning  tool, 


when  continued  to  fruition. 
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Appendix  A 

UNID  II  Data  Flow  Diagrams 

This  appendix  contains  the  Data  Flow  Diagrams  (DFD)  for  the  UNID  II 
which  were  developed  In  a  previous  thesis  effort  (30:26-34).  These  DFDs 
show  the  UNID  II  message  processing  functions  and  the  Internal  flow  of 
messages  between  the  local  and  network  I/O  hardware  ports.  The  DFDs  are 
still  current  and  are  shown  in  this  thesis  for  completeness.  The  DFDs 
are  presented  la  the  following  order: 
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A-l .  UNID  II  Overview  A-2 

A-2.  Input  Local  Information  A-3 

A- 3 .  Format  according  to  Outgoing  Protocol  A-4 

A-4.  Transmit  Network  Message  A-5 

A-1).  Input  Network  Information  A-6 

A- 7 
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Figure  A-l.  UNID  II  Overview  (30) 


•Igure  A-2.  Input  Local  Information  (30) 


Network  and  Message  Forma tte 

Local  Protocols  According  to 

Local  Protocol  , 


Figure  A-3.  Format  According  to  Outgoing  Protocol  (30) 


Figure  A-4 .  Transmit  Network  Message  (30) 
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is  connected 
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Figure  3-1.  RS-232C  Fin  Assignments 


The  local  side  connected  to  host  computers  or  terminals  will  use 
the  RS-232C  signals  shown  in  Figure  8-1.  It  is  assumed  that  the  RS- 


232C  interface  uses  a  standard  OB-25  connector. 


D3-37  Pin 
Number 


Signal  Nomenclature 


Direction 
In  Out 


Implemented 
In  DELNET 


Shield 

Signal  Rate  Indicator  A 
Spare  B 
Sand  Data  A 
Send  Timing  A 
Receive  Data  A 
Request  to  Send  A 
Receive  Timing  A 
Clear  to  Send  A 
Local  Loopback  A 
Data  Node  A 
Terminal  Ready  A 
Receiver  Ready  A 
Remote  Loopback 
Incoming  Call 

Select  Frequency  Signalling 
Rate  Indicator 
Terminal  Timing 
Test  Node  A 
Signal  Ground 
Receive  Common 
Spare  A 
Send  Data  3 
Send  Timing  B 
Receive  Data  B 
Request  to  Send  B 
Receive  Timing  B 
Clear  to  Send  B 
Terminal  in  Service  A 
Data  Node  8 
Terminal  Ready  8 
Receiver  Ready  3 
Select  Standby  A 
Signal  Quality 
New  Signal 
Terminal  Timing 
Standby  Indicator 
Send  Common 


NOTE:  The  -A  and  -B  suffixes  on  the  signal  nomenclature  refer 

to  the  non-lnverted  and  inverted  outputs/inputs  of  the  RS- 
422  signals  as  the  signals  use  a  balanced  signalling 
method  and  a  reversed  connection  will  invert  the  desired 


The  UNIDs  are  connected  using  the  RS-422  standard  on  the  data  Link 
layer  (subnetwork)  side  of  the  UNID.  Figure  B-2  shows  the  pin 
assignments  and  indicates  which  signals  are  currently  Implemented  In  the 
DELNET.  In  this  figure,  the  direction  Into  and  out  of  the  UNID  Is  also 
shown  to  clarify  the  use  of  a  null  modem  required  on  one  of  the  two  high 
speed  network  ports.  It  Is  assumed  that  the  RS-422  Interface  uses  a 
standard  DB-37  connector. 
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Introduction 


This  appendix  explains  implementation  errors,  and  their 
corrections,  from  previous  work  (29,  64,  75)-  The  hardware  errors  were 
detected  during  the  early  analysis  of  the  previous  designs  (64).  The 
hardware  errors  refer  to  the  revised  network  (data  link  layer)  board 
designed  by  (64).  WhLle  this  design  was  not  used  in  this  effort,  the 
errors  are  noted  for  future  reference.  The  software  errors  were 
discovered  during  the  early  analysis  of  the  previous  designs  and  during 
the  network  and  data  link  layer  software  simulations.  All  the  detected 
errors  have  been  corrected. 

Sof  tware  Corrections 

The  toggling  of  the  sequence  bit  in  the  transmitted  frame  for  the 
one  bit  sliding  window  protocol  was  forgotten.  The  sequence  bit  is 
never  toggled  in  the  l  frames,  even  though  the  R0UTE$0(JT  procedure  does 
toggle  the  sequence  bit  on  a  true  \CK.  Since  ROUTEJIN  checks  the  input 
sequence  bit  against  the  transmitted  sequence  bit  to  determine  a  true 
acknowledgement,  a  true  acknowledgement  will  only  occur  on  the  first 
transmitted  frame.  The  software  will  then  hang  up  resending  the  second 
frame  ad  infinitum.  The  corrective  action  is  to  include  the  sequence 
bit  In  the  3(JILD$ I$FRAME  procedure. 

A  counter  and  error  recovery  for  the  maximum  number  of 
retransmissions  in  the  ROUTEJOUT  procedure  is  needed.  There  currently 
is  none.  The  result  is  that  if  a  frame  is  never  acknowledged  and  the 
timer  times  out,  the  software  will  hang  up  sending  the  frame  forever! 
The  corrective  action  is  to  include  a  retransmission  counter  which  will 
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perform  a  specified  action  If  the  maximum  number  of  retransmissions  Is 
exceeded . 

The  design  for  Interpreting  the  Incoming  frame  In  the  NTOITB  and 
NT02T8  tables  is  Incorrect.  The  current  design  first  detects  if  the 
incoming  frame  is  to  continue  around  the  network  (NN)  or  is  destined  for 
the  local  UNID  (ML).  if  the  frame  is  NN,  then  an  S  frame  is  sent  to  the 
sender  of  the  frame  and  the  received  frame  is  then  sent  around  the  loop. 
This  situation  is  correct  for  an  I  frame,  but  causes  havoc  with  an  S 
frame,  in  effect,  S  frames  are  generated  as  acknowledgements  for  other 
3  frames  and  consequently,  S  frames  will  be  generated  at  a  geometric 
rate  and  will  choke  the  network.  The  ML  logic  is  satisfactory.  The 
solution  is  to  interpret  the  incoming  frame  to  determine  if  it  is  an  I 
or  S  frame,  then  determine  it's  destination.  This  solution  will  prevent 
S  frame  flooding  and  route  the  frames  correctly. 

A  problem  exists  in  the  ROUTE$OUT  procedure  when  ACKNOULEDGESA(B) 
is  true.  The  frame  to  send  is  correctly  discarded,  however, 
ACKNONTL£DGE$A(  B)  is  never  reset  false,  the  timeout  flag  and  counter  are 
not  reset,  and  the  number  of  retransmissions  counter,  assumed  to  be 
implemented,  is  not  initialized.  The  ACKNOWLEDGE$A(B)  reset  to  false 
was  placed  in  the  Incorrect  place.  This  will  only  allow  sending  the 
first  frame  whereupon  the  software  will  not  send  any  other  packets.  The 
corrective  action  Is  to  include  the  proper  resetting  of  the  flags  and 
counters  when  the  ACKNOWLEDGE!  A(B)  is  true. 

An  error  with  the  implementation  logic  of  the  one  bit  sliding 
window  timeout  and  the  acknowledge  exists.  Both  timeout  and  acknowledge 
need  to  be  considered  together  (37:43),  not  separately  as  implemented 


(75).  The  software  design  and  implementation  can  be  derived  from  the 


truth  table  In  Figure  C-l.  The  corrective  action  Is  to  Implement  the 
software  according  to  the  truth  table. 


ACK 

0 

0 

1 


TIMEOUT 

0 

L 

0 


FUNCTION 

Increment  TIMOUT  counter 

(re) send  a  frame 

service  transmit  table,  reset 
flags  and  counters 

same  as  the  (1,  0)  case 


Figure  C-l.  Acknowledge  and  Timeout  Truth  Table 


The  INP'jr$SEQ?BIT  and  TH1S$SEQ$BIT  require  the  suffix  '$A'  and  'SB' 
to  separate  the  sequencing  of  the  I  and  S  frames  for  the  A  and  B  loops  , 
otherwise  the  software  becomes  confused  when  both  the  A  and  3  directions 
are  transmitting  and  receiving  frames.  The  corrective  action  is  to 
implement  the  INl’U  T5SEQ$  BIT  and  THIS$SEQ$  BIT  for  both  the  $A  and  $8 
sections  of  software. 

The  original  software  design  does  not  insure  that  one  and  only  one 
C  frame  Is  in  the  0J  TFSAM  E$CHA(  B)$TB  table  at  a  given  instant  of  time. 
The  ore  bit  sliding  window  protocol  requires  that  the  current  I  frame  be 
retained  until  a  positive  acknowledgement  is  received.  If  two  or  more  I 
frames  are  in  the  transmit  buffer  at  the  same  time,  the  transmit 
software  will  send  them  both  and  subsequently  confuse  the  sequence  bits. 
This  results  in  the  software  continually  retransmitting  the  frames  until 
the  maximum  retransmit  counter  Is  exceeded.  The  corrective  action  Is  to 
generate  a  procedure  to  determine  if  an  l  frame  is  In  the  transmit 
buffer  and  inform  the  calling  procedure  accordingly.  The  calling 
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procedure  should  then  load  an  I  frame  only  when  there  Is  no  I  frame  In 
the  transmit  buffer. 

An  error  exists  with  the  Implementation  of  the  bit  masking  used  for 
the  detection  of  the  acknowledge  frames  and  the  sequence  bits.  The  bit 
masking  was  Implemented  in  reverse  order,  that  is  the  eighth  bit  Is 
masked  for  detection  of  an  S  frame  where  the  first  bit  should  be  masked. 
Similarly,  the  sixth  bit  is  masked  for  detection  of  the  sequence  bit 
where  the  third  bit  should  be  masked.  The  source  of  the  problem  is 
interpretation  between  the  left  to  right  ordering  of  the  bits  In  the 
source  documentation  and  the  left  to  right  Implementation  in  the 
software.  The  source  documentation  shows  the  least  significant  bit  on 
the  left  and  the  most  significant  bit  on  the  right,  however  the  bit  mask 
coding  is  just  reversed  with  the  most  significant  bit  on  the  left  and 
the  least  significant  bit  on  the  right.  This  reversal  did  not  affect 
the  original  implementation  because  the  software  was  the  same  at  both 
ends  of  the  UNID  connection  and  each  end  saw  the  correct  information 
where  it  should  have.  Consequently,  this  error  was  not  previously 
detected.  The  corrective  action  is  to  implement  the  bit  masking 
correctly. 

The  3U ILD$ I$PACKET  procedure  in  the  original  network  layer  software 
contained  a  case  statement  that  performed  the  same  assignment  statements 
regardless  of  the  case  selector  (64,  75).  While  this  Is  not  an  error  to 
the  software  as  it  than  existed,  it  did  use  extra  memory.  The  procedure 
was  rewritten  using  pointers  and  semaphores  as  explained  in  Chapter 


Hardware  Corrections 


A  design  error  exists  In  network  board  schematic.  Data  lines  D8  - 
D15  and  DO  -  D7  In  the  memory  array  need  to  be  controlled  by  AO  and  8HE* 
(generated  by  the  3089  processor),  otherwise  the  memory  will  not  be 
accessed  correctly  for  byte  read/write  operations.  The  corrective 
action  is  to  redesign  the  memory  data  control  similar  to  the  SBC  86/12A 
logic  to  properly  gate  the  memory  data. 

A  design  or  typographical  error  exists  with  the  address  decoding 
lines  for  the  8039  local  I/O  space.  The  address  lines  Al4  and  A15  are 
reversed.  The  corrective  action  is  to  implement  the  addressing 
correctly  and  annotate  the  schematic  diagram. 

The  RS  232/422  DTE/DCE  strapping  options  shown  on  the  schematic  are 
in  the  incorrect  locations.  They  need  to  be  between  the  connectors  and 
drivers,  not  between  the  USART  and  the  drivers,  otherwise  the  drivers 
are  connected  output  to  output  and  input  to  input  with  the  USART.  The 
corrective  action  is  to  redesign  the  strapping  options  in  the  correct 
location  and  annotate  the  schematic  diagram. 


DELNET/UNID  Header  Information 


This  appendix  expands  upon  the  TCP/IP  datagram,  packet,  and  frame 
header  Information  presented  briefly  in  Chapter  One  (75:Appen  C).  Each 
byte  Ln  a  complete  datagram,  packet,  and  frame  is  shown  with  the 
appropriate  bit  information  within  each  byte.  The  name  of  each  byte 
position,  along  with  the  array  index  number,  is  given  for  each  byte. 
The  subscripts  H  and  L  refer  to  most  significant  byte  and  least 
significant  byte,  respectively.  Similarly,  the  subscripts  3,  2,  and  1 
indicate  the  most  significant  byte,  the  next  significant  byte  and  the 
Least  significant  byte,  respectively.  The  contents  of  each  byte  conform 
to  the  standards  established  in  (28,  67  ,  69  ,  75:.\ppen  C).  Entries  that 
contain  letters  refer  to  specific  bits  that  must  be  initialized  or  set 
according  to  how  and  when  they  are  used.  For  example,  the  packet  source 
address  will  be  a  constant  that  depends  upon  the  particular  UNID  and 
port  number  to  which  a  host  is  connected.  The  Type  of  Service  byte  on 
page  D-2  depends  upon  the  precedence,  delay,  throughput  and  routing 
required  by  the  transport  and  higher  level  protocols.  Those  bits  and 
bytes  that  contain  letters  are  variables  that  are  data  and  user 
dependent.  Those  bytes  that  are  empty  are  not  yet  used  by  the  UNID  II 
software  and  are  currently  filled  with  zeros.  The  particular  mapping 
shown  was  used  for  the  testing  of  the  UNID  II  in  the  LSI— i L  NEIOS  test. 
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Figure  D-l.  DELiVEr/UNID  Detailed  Header  Information 


This  appendix  explains  in  detail  the  use  of  semaphores  as 
Implemented  for  the  exchange  of  information  between  the  SBC  544  and  SBC 
58/45  boards. 

The  use  of  semaphores  is  required  to  protect  a  critical  region 
(13:73)  of  program  execution  from  being  disturbed  by  other  concurrent 
processes  in  a  multiprocess  or  multiprocessor  environment.  As  was 
earlier  noted,  the  UNID  I  and  II  are  multiprocessor  and  multiprocess 
systems.  Data  in  the  form  of  packets  are  exchanged  between  the  two 
processors.  The  process  on  the  SBC  544  board  which  alerts  the  SBC  88/45 
board  chat  a  packet  is  ready  for  the  SBC  83/45  process  must  ensure  that 
the  SBC  83/45  process  is  not  manipulating  the  last  set  of  data  left  by 
the  SBC  544  process,  otherwise  the  SBC  544  process  will,  in  all 
likelihood,  write  over  the  old  data  with  the  new  data  and  cause 
inadvertent  destruction  of  desired  data  (13:77). 

Squally  as  Important,  the  SBC  88/45  process  must  ensure  that  the 
SBC  544  process  is  not  manipulating  data  in  the  critical  region  of 
memory  when  the  SBC  33/45  process  wants  access  to  the  critical  region. 
The  method  to  ensure  a  wrlteover  (race)  condition  does  not  exist  often 
involves  the  use  of  P  and  V  type  semaphore  operators  (13:89).  The  P  and 
7  operators  are  often  implemented  with  low  level  hardware  operations, 
5uch  as  TestAndSet  which  is  called  LOCK  for  the  Intel  processors,  that 
will  interrogate  and  set  a  flag  to  ensure  that  only  one  process  is 
manipulating  data  In  a  critical  region  of  memory  at  one  time, 
"nf or tunately,  as  mentioned  in  Chapter  Three  of  this  thesis,  the  SBC  544 


board  does  not  have  the  TestAndSet  (LOCK)  capability  even  though  the  SBC 
38/45  board  does.  The  SBC  544  board  also  does  not  have  the  mechanisms 


to  allow  the  SBC  38/45  board  to  use  Its  LOCK  operator.  Therefore 
another  method  was  devised  which  allows  both  boards  to  share  certain 
portions  of  the  common  system  memory  while  allowing  only  one  processor 
and  process  to  access  that  shared,  critical  region  at  one  time,  thus 
preventing  inadvertent  destruction  of  data  (13:77).  This  method  uses  a 
variable  with  only  two  states,  Ready  and  Done,  as  the  semaphore.  The 
SBC  544  process  will  check  the  variable  for  the  Done  state,  and  if  Done, 
will  update  the  packet  pointer  and  set  the  semaphore  to  the  Ready  state. 
The  SBC  33/45  process  checks  for  the  Ready  state,  and  If  Ready,  will 
move  the  packet  to  another  buffer  for  further  processing  and  set  the 
semaphore  to  the  Done  state.  The  SBC  544  process  Is  allowed  only  to 
check  the  semaphore  for  Done  and  set  the  semaphore  to  Ready.  The  SBC 
33/45  process  is  allowed  only  to  check  the  semaphore  for  Ready  and  set 
the  semaphore  to  Done.  By  Implementing  the  processes  In  this  manner, 
the  processes  will  stay  in  synchronization  and  not  manipulate  data  until 
the  data  Is  ready  to  be  manipulated.  Each  process  is  not  allowed  to 
wait  until  the  other  process  is  completed;  It  will  continue  performing 
other  tasks  and  will,  at  some  later  time,  reenter  the  semaphore  testing 
routine.  This  mechanism  is  illustrated  in  Figure  E-l  with  the  aid  of 


pseudocode . 


If  DatagramAvailable  then  (Process  ex 

If  LSem  =  Done  then 
do; 

LPointer  =  .LocalReceive(NexttoSend) 
LSem  *  Ready 

service( .LocalRecelve(NexttoSend) ) 
end; 


(Process  executed  by  SBC  544) 


If  LSem  *  Ready  then  (Process  executed  by  SBC  88/45) 

do; 

move(LPointer ,  .NetworkTrans.Tiit(NextEmpty),  PacketSize) 

LSem  *  Done 

load( .NetworkTransmlt(NextEmpty) ) 
end; 


Figure  E-l.  Pseudocode  for  SBC  544  to  SBC  88/45  Packet  Movement 


The  first  section  of  pseudocode  corresponds  to  the  process  on  the 
SBC  544  board  and  the  second  section  of  pseudocode  corresponds  to  the 
concurrent  process  on  the  SBC  88/45  board.  DatagramAvailable  Is  an 
Indication  that  a  packet  is  available  to  move  to  the  network  board, 
LPointer  Is  a  pointer  to  the  available  packet,  LSem  Is  the  semaphore, 
•LocalRecelve(NexttoSend)  Is  the  pointer  to  the  available  packet  In  the 
SBC  544  memory,  .NetworkTransmlt(NextEmpty)  Is  the  pointer  to  the  next 
available  entry  for  a  packet  in  the  SBC  88/45  memory.  LPointer  and 
LSem,  as  well  as  the  packet,  are  stored  In  the  shared  system  memory. 
The  routines  'service'  and  'load'  adjust  the  pointers  within  the  tables 
given  as  arguments  and  'move'  moves  a  specified  amount  of  data  from  one 
location  to  a  second  location.  The  reader  should  recall  that  the  tables 
LocalReceive,  LocalTransmi t,  NetworkReceive  and  NetworkTransralt  used  In 
the  ONID  software  are  circular  FIFO  queues  whose  flrst-ln  pointer  Is 
NextEmpty  and  first-out  pointer  Is  NexttoSend. 

The  above  high  level  code  Is  divisible  Into  smaller  sets  of 
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indivisible  assembly  language  code,  each  of  which  can  be  interrupted  by 
other  processes  on  the  respective  SBC  544  or  SBC  83/45  board.  The 
sections  of  code  that  can  interrupt  the  above  processes,  however,  do  not 
manipulate  any  data  used  by  the  above  sections  of  code,  and  will 
therefore  not  disturb  the  critical  sections  except  for  inducing  a  non 
critical  time  delay.  In  addition,  the  remaining  processes  on  each  board 
never  manipulate  the  semaphore.  The  LocalReceive  buffer  is  used  by 
other  SBC  544  processes.  These  are  the  host  receive  interrupt  routine, 
where  the  table  pointer  NextEmpty  is  manipulated,  and  the  send  a 
datagram  from  local  host  to  local  host  routine  where  the  table  pointer 
NexttoSend  is  manipulated.  The  latter  routine,  while  manipulating  the 
NexttoSend  pointer,  will  only  do  so  when  the  particular  datagram;  is  for 
local  to  local  host  movement.  The  particular  routine  ol'  which  the  aoova 
code  is  a  part  interrogates  the  IP  header  of  the  first  datagram  pointed 
to  by  NexttoSend.  If  this  datagram  is  for  local  host,  to  local  host 
movement,  the  datagram  is  moved  and  the  NexttoSend  pointer  updated. 
However,  if  the  datagram  is  for  local  host  to  network  movement,  the 
first  section  of  pseudocode  above  is  called.  The  pointer  NexttoSend 
will  only  be  updated  if  the  SEC  88/45  is  ready  for  another  packet, 
otherwise  the  pointer  is  left  untouched  and  the  datagram  in  question  is 
still  at  the  top  of  the  LocalReceive  table  waiting  to  be  moved.  So 
while  the  NexttoSend  pointer  can  be  manipulated  by  another  process,  it 
Is  done  so  only  if  the  datagram  in  question  at  the  top  of  the 
LocalReceive  table  Is  going  back  to  a  local  host  and  not  to  the  network. 
Therefore  the  NexttoSend  pointer  will  be  updated  for  a  network  destined 
packet  only  if  the  datagram  in  question  at  the  top  of  the  LocalReceive 
table  is  going  to  the  network  when  the  first  section  of  the  pseudocode 
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is  entered. 


It  should  be  noted  that  while  both  processors  have  the  ability  to 
access  the  shared  system  memory  at  the  same  time,  and  will  probably 
attempt  to  do  so,  they  cannot,  in  fact,  read  (or  write)  to  the  same 
shared  location  at  exactly  the  same  instant.  This  'read  at  the  same 
instant'  phenomena  is  prevented  oy  the  hardware  design  of  Doth  boards. 
If  the  SBC  544  processor  is  in  the  middle  of  a  fetch  from  shared  memory, 
the  hardware  design  locks  out  access  to  the  memory  to  other  processors 
with  access  to  that  shared  memory.  Therefore,  the  SBC  88/45  board 
cannot  access  the  desired  location  until  the  SBC  544  board  has  completed 
its  current  instruction,  whereupon,  the  SBC  88/45  may  then  access  the 
shared  memory.  The  same  holds  true  for  an  access  of  shared  memory  by 
the  SBC  88/45  board.  When  the  SBC  88/45  processor  accesses  shared 
memory,  other  processors  are  locked  out  from  accessing  the  same  shared 
memory  until  the  SBC  88/45  has  completed  its  current  instruction. 
Therefore,  if  the  SBC  88/45  is  executing  the  instructions  to  set  'LSem  = 
Done',  and  the  SBC  544  is  fetching  the  'LSem'  location  to  interrogate 
for  'Done',  there  will  not  be  a  simultaneous  access  of  the  location 
'LSem'  as  explained  above.  Therefore  the  SBC  544  Interrogation  of 
'LSem'  will  find  its  value  either  'Done'  or  'Ready'  as  expected  and 
execute  the  critical  section  accordingly. 

The  process  communication  from  the  SBC  88/45  board  to  the  SBC  544 
board  is  identical  to  that  for  the  SBC  544  to  SBC  88/45  board  explained 
above.  The  variable  names  are  different  so  as  to  keep  the  two  processes 
and  functions  separated.  The  two  processes  function  the  same  and  the 
discussion  above  applies  to  the  SBC  88/45  to  SBC  544  board 
communication.  The  pseudocode  for  the  SBC  88/45  to  SBC  544  board 


E  -  5 


Appendix  F 


Transcil  t  Request/Transmit  Acknowledge  Handshake 

This  appendix  explains  the  details  of  the  transmit  reques t/ transm 1 t 
acknowledge  mechanism  implemented  in  the  SBC  544  local  host  software. 

The  transmit  request/transmit  acknowledge  mechanism  is  used  to 
synchronize  the  UN'ID  II  network  layer  software  with  a  comparable  process 
on  a  local  host.  The  mechanism  allows  the  orderly  transmission  of 
datagrams  between  the  host  and  the  UNID  II.  This  allows  the  UN1D  II  to 
reliably  send  and  receive  datagrams  from  a  host  that  is  slower  than  the 
speed  of  the  UN’ID  II,  whether  the  host  polls  the  receive  port  or  has  a 
slow  interrupt  response,  or  a  host  that  does,  not  have  an  interrupt 
driven  receive  port  from  the  UN’ID  II.  This  mechanism,  or  something 
similar  such  as  the  DTR-DSR  or  RTS-CTS  hardware  handshake,  must  be 
implemented  to  allow'  the  orderly  transmission  of  datagrams  between  the 
UN’ID  II  and  its  connected  hosts.  The  particular  implementation 
explained  below  was  chosen  to  accommodate  the  NEIOS  (LSI-11)  network  in 
the  DELNE1,  which  uses  a  software  transmit  reques t/ transmit  acknowledge 
scheme.  The  NETOS  uses  does  not  use  a  hardware  handshake  such  as  the 
RTS-CTS  because  the  signals  are  not  implemented  on  that  system.  Other 
mechanisms,  such  as  XON-XOFF,  may  be  relatively  easily  implemented  in 
the  UNID  II  software  to  accommodate  similar  the  mechanisms  in  ether 
ne  tworks . 

The  particular  mechanism  used  by  the  NETOS  can  be  described  as 
follows  (72).  When  a  node  in  the  NETOS  desires  to  send  a  packet  to 
another  node,  it  first  sends  a  transmit  request  (TR)  to  the  desired 
node.  The  receiving  node  then,  when  it  recognizes  a  TR  was  sent  to  it, 


will  send  a  transmit  acknowledge  (TA)  back  to  the  sender  when  it  is 
ready  to  receive  a  packet.  The  sending  node,  when  it  recognizes  the  TA 
from  the  receiving  node,  sends  the  datagram  to  the  receiving  node. 
There  is  no  final  acknowledge  sent  by  the  receiver  back  to  the  sender  to 
acknowledge  the  reception  of  the  datagram.  The  TR/TA  mechanism 
effectively  reduces  a  normally  full  duplex  channel  to  a  half  duplex 
channel.  The  process  can  be  diagrammed  as  shown  in  Figure  F-l. 


Node  A 


Node  B 


Datagram  to  send 


Recv  TR  <- 


Send  TR 


Wait  for  TA 


Send  TA 


■>  Recv  TA 


Look  for 
Datagram 


Recv  Datagram 


Datagram 


Send  Datagram 


Figure  F-l.  NETOS  Transmit  Request/ Transmit  Acknowledge  Handshake. 


The  mechanism  is  implemented  in  the  UNID  II  software  with  four 
boolean  flags  for  each  host  port.  Four  flags  are  required  since  both 
the  NETOS  node  and  the  UNID  will  send  and  receive  datagrams  using  the 
TR/TA  mechanism,  providing  a  full  handshake  for  each  direction.  The 
UNID  must  know  which  state  it  is  in  so  that  it  can  communicate  correctly 
with  the  NETOS  node.  The  four  flags  are  Transmit  transmit  request 
(TXTR),  Receive  transmit  acknowledge  (RXTA),  Receive  transmit  request 


(RXTR),  and  Transmit  transmit  acknowledge  (TXTA).  Each  flag  has  the 


value  TRUE  or  FALSE.  The  Initial  state  is  all  four  flags  FALSE.  Of  the 


16  possible  states,  the  five  allowed  states  are  shown  in  Figure  F-2.  A 
'0'  represents  FALSE  and  a  '1'  represents  TRUE. 


Figure  F-2.  UNID  TR/TA  Allowable  States. 


Note  that  the  mechanism  starts  in  the  all  zero,  or  FALSE,  state 
with  no  datagrams  to  send  or  receive  and  returns  to  the  all  zero  state 
at  the  completion  of  sending  or  receiving  a  datagram.  Also,  only  one 
process  of  sending  a  datagram  or  receiving  a  datagram  is  allowed  at  one 
time.  While  this  is  a  requirement  for  the  NETOS,  and  possibly  other 
networks,  the  UNID  software  is  totally  interrupt  driven  and  can  send  and 
receive  a  datagram  simultaneously  without  this  handshake  mechanism.  The 
UNID  II  local  software  on  the  544  board  has  been  designed  through  the 
use  of  a  boolean  flag  labeled  TRTA  so  that  the  TR/TA  half  duplex 
handshake  may  be  used  or  not  used  on  any  given  host  port  of  the  544 


Appendix  G 

Data  Dictionary 


This  appendix  contains  the  data  dictionary  for  the  four  programs 
that  comprise  the  network  and  data  link  layer  simulations,  the 
validation  and  test  programs  used  with  the  UNID  II  and  NETOS,  and  the 
host  CP/M  simulation  software  (Chapter  Five). 

The  simulation  dictionaries  are  presented  first  followed  by  the 
dictionary  for  the  software  on  the  SBC  544  and  the  CP/M  system.  Each  of 
the  four  programs  has  its  own  subdictionary  which  contains  a  section  for 
constants,  variables,  and  procedures.  Each  entry  is  listed  in 
alphabetical  order. 

The  batch  files  used  to  link  and  locate  the  object  code  generated 
by  the  compiler  are  also  included  at  the  end  of  each  applicable 
subdictionary. 

The  appendix  is  subdivided  into  four  subdictionaries  which  are 


listed  as  follows: 

Subdictionary  Page 

1.  Network  Layer  Simulation  .  G-2 

2.  Data  Link  Layer  Simulation . G-7 

3.  SBC  544  Validation . G-12 

4.  Host  CP/M . G-16 
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1 .  Network  Layer  Simula  ti on 


The  purpose  of  this  program  is  to  simulate  the  network  layer 

software  on  the  Intel  Software  Development  System. 

Constants 

ASCII(*)  -  Array  of  ASCII  characters  used  for  converting  binary  to  hex 
and  hex  to  binary  numbers  for  display  on  the  console. 

DATA$GRAM$SIZE  -  Number  of  bytes  in  a  datagram  (128)  received  from  a 
host. 

DATA$TABLE$SIZE  -  Number  of  bytes  within  a  data  table. 

L$Rl$DESr$ERR  -  Local  route  in  destination  error. 

L$RO$DEST$ERR  -  Local  route  out  destination  error. 

MAX$C0UN TRYJCODE  -  Maximum  number  of  countries  operational  on  the 
DELNET. 

MAX$ NETWORK! CODE  -  Maximum  number  of  UNIDs  operational  within  a 
particular  country. 

PACKET$SIZE  -  Number  of  bytes  in  a  packet  (133). 

PACKETS$IN$TABLE  -  Number  of  packets  in  a  packet  table. 

PACKET$TABLE$SIZE  -  Number  of  bytes  in  a  packet  table. 

R$CONN  -  I/O  handle  number  for  ISIS  console  call. 

STAT$NBR  -  Number  of  the  status  entries  to  be  included  in  the  status 
table . 

SYS$MEM$BASE  -  Base  address  used  to  locate  the  shared  table  and 
variables . 

SYS$BASE  -  Base  label  used  to  properly  locate  the  shared  table  and 
variables.  Used  with  SYS$MEM$BASE. 

THIS$COUNTRY$CODE  -  Unique  code  indicating  in  which  country 
THIS$UNID$NBR  resides. 

THIS$UNID$NBR  -  Unique  UNID  number  for  the  UNID  performing  the  interface 
between  local  hosts  and  the  DELNET. 

TCP$DATA$SIZE  -  Number  of  user  data  bytes  in  the  TCP  header. 


TA  -  Transmit  acknowledge  character. 

TK  -  Transmit  request  character. 

W$CONS  -  I/O  handle  number  for  ISIS  console  call. 

Variables 

ACTUAL  -  Number  of  characters  returned  from  ISIS  console  read  call. 

BUFFER  -  128  byte  buffer  used  with  ISIS  console  read  call. 

DESTINATION  -  Indicates  whether  a  received  datagram  is  destined  for  the 
network  or  another  attached  local  host. 

DESTINATIONSADDRESS  -  Indicates  the  destination  address  of  a  datagram. 

SOURCE$ADDRESS  -  Indicates  the  source  address  of  a  datagram. 

ERRNUM  -  Number  of  the  error  returned  from  an  ISIS  system  call. 

LC01NE  -  Pointer  in  the  array  LC01TB  pointing  to  the  next  available 
position  for  a  received  datagram. 

LC02NE  -  Pointer  in  the  array  LC02TB  pointing  to  the  next  available 
position  for  a  received  datagram. 

LC03NE  -  Pointer  in  the  array  LC03TB  pointing  to  the  next  available 
position  for  a  received  datagram. 

LC04NE  -  Pointer  in  the  array  LC04TB  pointing  to  the  next  available 
position  for  a  received  datagram. 

LC01NS  -  Pointer  in  the  array  LC01TB  pointing  to  the  next  datagram  to 
service . 

LC02NS  -  Pointer  in  the  array  LC02TB  pointing  to  the  next  datagram  to 
service . 

LC03NS  -  Pointer  in  the  array  LC03TB  pointing  to  the  next  datagram  to 
service. 

LC04NS  -  Pointer  in  the  array  LC04TB  pointing  to  the  next  datagram  to 
service . 

LC01SZ  -  The  maximum  number  of  bytes  in  the  LC01TB  array. 

LC02SZ  -  The  maximum  number  of  bytes  in  the  LC02TB  array. 

LC03SZ  -  The  maximum  number  of  bytes  in  the  LC03TB  array. 

LC04SZ  -  The  maximum  number  of  bytes  in  the  LC04TB  array. 


LC01TB  -  Local  receive  table  for  host  port  number  one. 
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LC02TB  -  Local  receive  table  for  host  port  number  two. 

LC03TR  -  Local  receive  table  for  host  port  number  three. 

LC04IB  -  Local  receive  table  for  host  port  number  four. 

LPTR$1,  LPTR$2 ,  LPTR$3,  LPTR54  -  Pointer  to  the  current  packet  to  be 

passed  to  the  data  link  layer. 

LSEM$ 1 ,  LSEh$2,  LSEM$ 3 ,  LSE*i$4  -  Semaphore  used  by  the  network  and  data 
link  layers  to  indicate  the  state  of  the  packet  transfer. 

LSPAR£$1 ,  LSPARE$2 ,  LSPARE$3,  LSPARE$4  -  Spare  memory  locations  used  by 
the  SBC  83/45  for  it's  pointer  transfer. 

NPrR$l,  NPTR$2,  NPTR$3,  LPTR$4  -  Pointer  to  the  current  packet  to  be 
passed  to  the  network  layer. 

NSEM$  1 ,  NSEM$2 ,  NSEM$3,  NSEM$4  -  Semaphore  used  by  the  network  and  data 
link  layers  to  indicate  the  state  of  the  packet  transfer. 

NSPAREJ1,  NSPARES2,  NSPARE$3,  NSPARE$4  -  Spare  memory  locations  used  by 
the  SBC  88/45  for  it's  pointer  transfer. 

TX01NE  -  Pointer  in  the  array  TX01TB  pointing  to  the  next  available 
position  for  a  transmitted  datagram. 

TX02NE  -  Pointer  in  the  array  TX02TB  pointing  to  the  next  available 
position  for  a  transmitted  datagram. 

TX03NE  -  Pointer  in  the  array  TX03TB  pointing  to  the  next  available 
position  for  a  transmitted  datagram. 

TX04NE  -  Pointer  in  the  array  TX04TB  pointing  to  the  next  available 
position  for  a  transmitted  datagram. 

TX01NS  -  Pointer  in  the  array  TX01TB  pointing  to  the  next  datagram  to 
service. 

TX02NS  -  Pointer  in  the  array  TX02TB  pointing  to  the  next  datagram  to 
service . 

TX03NS  -  Pointer  in  the  array  TX03TB  pointing  to  the  next  datagram  to 
service . 

TX04NS  -  Pointer  in  the  array  TX04TB  pointing  to  the  next  datagram  to 
service . 

TX01SZ  -  The  maximum  number  of  bytes  in  the  TX01 TB  array. 

TX02SZ  -  The  maximum  number  of  bytes  in  the  TX02TB  array. 
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TX03S2  -  The  maximum  number  of  bytes  in  the  TX03TB  array. 
TX04SZ  -  The  maximum  number  of  bytes  In  the  TX04TB  array. 
TX01TB  -  Local  receive  table  for  host  port  number  one. 

TX02TB  -  Local  receive  table  for  host  port  number  one. 

TX03TB  -  Local  receive  table  for  host  port  number  one. 

TX04TB  -  Local  receive  table  for  host  port  number  one. 

MESSAGE(*)  -  Test  message  array. 

STATUS  -  Error  status  of  ISIS  console  I/O  calls. 


Procedures 


DETSADDR  -  Determine  the  destination  of  the  datagram  from  the  attached 
host. 

DET$ADDR$NL  -  Determine  the  destination  of  the  datagram  passed  from  the 
data  link  layer. 

ERROR  -  I/O  error  handler  for  ISIS  operating  system  calls. 

EXIT  -  Graceful  method  to  end  the  simulation;  returns  to  the  ISIS 
operating  system. 

INIT  -  Initializes  the  variables  to  their  initial  states. 

INIT$IAB  -  Initializes  the  network  and  data  link  layer  tables  and 
pointers  to  their  initial  values. 

LD$TAB$HSKP  -  Housekeep  a  specified  buffer  table  load  pointer. 

LOOP  -  Simulates  the  semaphore  check  and  set  operation  of  the  SBC  8S/45 
board  to  turn  a  frame  around  to  the  network  layer. 

MOVETO$LOCAL  -  Move  a  datagram  from  a  receive  host  buffer  or  the  data 
link  layer  buffer  to  the  local  host  transmit  buffer. 

READ  -  Read  a  line  of  character  Input  from  the  console;  an  ISIS 
operating  system  call. 

ROUTE$IN  -  Route  received  datagrams  from  the  local  hosts  to  the  data 
link  layer  or  the  local  host  transmit  buffers. 

ROUTE$OUT  -  Send  the  datagrams  In  the  transmit  buffers  to  the  local 
hosts. 


SENDiPACKET  -  Transf orming  the  user  datagram  into  a  packet  for  transfer 
to  the  data  link  layer. 

SERVICC$LOOP  -  Turns  a  frame  around  at  the  data  link  layer.  The  source 
and  destination  headers  are  exchanged. 

SET$TRTA  -  Queries  operator  for  which  host  channels  will  use  the  TRTA 
handshake . 

SNDSEQ  -  Takes  a  message  string  from  the  calling  procedure  and  outputs 
it  to  the  ISIS  operating  system. 

SRVC$TAB$HSKP  -  Housekeep  a  specified  buffer  table  service  pointer. 

WRITE  -  Write  a  line  of  character  information  to  the  console;  an  ISIS 
operating  system  call. 

Link  and  Locate  Batch  File 

CAu'TION:  Do  not  change  address  or  other  parameters  in  the 
following  batch  file.  They  are  highly  hardware  dependent 
on  the  System  III  and  the  ISIS  operating  system. 

LINK  NEWLOC . OBJ  , SYSTEM . LIB , PLM8Q  .LIB  TO  NEWLOC. LNK  MAP 

LOCATE  NEWLOC.LNK  TO  NEWLOC  STACKSIZE( 100H)  ORDER ( CODE, DATA , & 

STACK, MEMORY)  CODE(5000H)  MAP  PRINT( NEWLOC. MP2) 

TYPE  NEWLOC. MP2 


2 .  Data  Link  Layer  Simulation 

The  purpose  of  this  program  Is  to  simulate  the  data  link  layer 
software  on  the  Intel  Software  Development  System. 

Constants 

ASCII(*)  -  Array  of  ASCII  characters  used  for  converting  binary  to  hex 
and  hex  to  binary  numbers  for  display  on  the  console. 

CONCTC  -  Network  monitor  counter  timer  port  address. 

CONCMD  -  Network  monitor  USART  command  port  address. 

CONDAT  -  Network  monitor  USART  data  port  address. 

DATA$GRAM$SIZE  -  Number  of  bytes  in  a  datagram  (128)  received  from  a 
host. 

DATA$ TABLEJSIZE  -  Number  of  bytes  within  a  data  table. 

L$RI$DEST$ERR  -  Local  route  in  destination  error. 

L$RO$DEST$ERR  -  Local  route  out  destination  error. 

MAX$COUNTRi$CODE  -  Maximum  number  of  countries  operational  on  the 
DELNET. 

MAX$NETWORK$CODE  -  Maximum  number  of  UNIDs  operational  within  a 
particular  country. 

MAXNOA  -  Maximum  number  of  timing  counts  for  network  channel  A. 

MAXNOB  -  Maximum  number  of  timing  counts  for  network  channel  B. 

MAXRETRANS$A  -  Maximum  number  of  retransmissions  of  a  frame  for  network 
channel  B. 

MAXRETRANS$B  -  Maximum  number  of  retransmissions  of  a  frame  for  network 
channel  B. 

PACKET$SIZE  -  Number  of  bytes  in  a  packet  (133). 

PACKETS$IN$TABLE  -  Number  of  packets  In  a  packet  table. 

PACKET$TABLE$SIZE  -  Number  of  bytes  in  a  packet  table. 

R$CONN  -  I/O  handle  number  for  ISIS  console  call. 
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STAf$NBR  -  Number  of  the  status  entries  to  be  included  in  the  status 
table . 

THIS$COUNTRY$CODE  -  Unique  code  indicating  in  which  country 
TUIS$UNID$NBR  resides. 

TdIS$UNID$NBR  -  Unique  UNID  number  for  the  UNID  performing  the  interface 
between  local  hosts  and  the  DELNET. 

TCP$DATA$S1ZE  -  Number  of  user  data  bytes  in  the  TCP  header. 

W$CONN  -  I/O  handle  number  for  ISIS  console  call. 

Variables 

ACTUAL  -  Number  of  characters  returned  from  ISIS  console  read  call. 

BUFFER  -  128  byte  buffer  used  with  ISIS  console  read  call. 

CTCNOA  -  Progressive  number  of  time  counts  for  network  channel  A. 

CTCNOB  -  Progressive  number  of  time  counts  for  network  channel  B. 

DESTINATION  -  Indicates  whether  a  received  datagram  is  destined  for  the 
network  or  another  attached  local  host. 

SOU RCE$ ADDRESS  -  Indicates  the  source  address  of  a  datagram. 

ER.RNUM  -  Number  of  the  error  returned  from  an  ISIS  system  call. 

INPUT$SEQ$BIT$A  -  Input  sequence  bit  number  for  channal  A. 

INPUT$SEQ$BIT$B  -  Input  sequence  bit  number  for  channel  B. 

LCNTNE  -  Pointer  in  the  array  LCNTIB  pointing  to  the  next  available 
position  for  a  received  datagram. 

LCNTNS  -  Pointer  in  the  array  LCNTTB  pointing  to  the  next  datagram  to 
service . 

LCNTSZ  -  The  maximum  number  of  bytes  In  the  LCNTTB  array. 

LCNTIB  -  Local  to  network  table. 

NTLCNE  -  Pointer  in  the  array  NTLCTB  pointing  to  the  next  available 
position  for  a  received  datagram. 

NT01NE  -  Pointer  in  the  array  NT01TB  pointing  to  the  next  available 
position  for  a  received  datagram. 

NT02NE  -  Pointer  in  the  array  NT02TB  pointing  to  the  next  available 
position  for  a  received  datagram. 


NTLCNS  -  Pointer  in  the  array  NTLCTB  pointing  to  the  next  datagram  to 
service . 

NTU1NS  -  Pointer  in  the  array  NTOlfB  pointing  to  the  next  datagram  to 
service. 

NT02NS  -  Pointer  in  the  array  NT02TB  pointing  to  the  next  datagram  to 
service. 

NTLCSZ  -  The  maximum  number  of  bytes  in  the  NTLCTB  array. 

NTOiSZ  -  The  maximum  number  of  bytes  in  the  NTG1T8  array. 

NT02SZ  -  The  maximum  number  of  bytes  in  the  N TO 2TB  array. 

NTLCTB  -  Local  receLve  table  for  host  port  number  two. 

Ni'OlTB  -  Local  receive  cable  for  host  poi  t  number  three. 

NT02TB  -  Local,  receive  table  for  host  port  number  four. 

ML3SAGE(*)  -  lest  message  array. 

OUTFRAME$CHA$NE  -  Pointer  in  the  array  OUTPRAME$CHA$TB  pointing  to  the 
next  available  position  for  a  transmitted  datagram. 

OU  T  FR  A  M  E  $  CH  B$  N  E  -  Pointer  in  the  array  OU TFRArtE$CHB$TB  pointing  to  the 
next  available  position  for  a  transmitted  datagram. 

OU f FRAME$CHA$HS  -  Pointer  in  the  array  OUTFRAME$CHA$TB  pointing  to  the 
next  datagram  to  service. 

OUTFRAMEJ CUB$NS  -  Pointer  in  the  array  OUTFRAMK$CUB$ IB  pointing  to  the 
next  datagram  to  service. 

OUTFKAiTL$CHA$SZ  -  The  maximum  number  of  bytes  in  the  Ob  i’FRAME$CHA$TB  array 

OUT FRAME$CHB$SZ  -  The  maximum  number  of  bytes  in  the  OUTFRAriE$CHB$TB  array 

OUTFKAME$CHA$  I'B  -  Local  receive  table  for  host  port  number  one. 

OUTFRAME$CHB$TB  -  Local  receive  table  for  host  port  number  one. 

OUTf TAB$FULL  -  Boolean  to  determine  when  the  network  transmit  table 
contains  a  frame. 

RETkANS$A  -  Progressive  number  of  retransmissions  of  a  frame  for  channel 

A. 

RETRANo$B  -  Progressive  number  of  retransmissions  of  a  frame  for  channel 
A. 

SEG$BIT$A  -  Frame  acknowledge  bit  for  channel  A. 


$EQ$Bir$B  -  Frame  acknowledge  bLt  for  channel  b. 

STATUS  -  Error  status  of  ISIS  console  1/0  calls. 

TillS$SEQ$BI?$A  -  Current  sequence  bit  for  frame  to  transmit  in  channel  A. 

TrlIS$SEO$bI  l’$il  -  Current  sequence  bit  for  frame  to  transmit  in  channel  b. 

1IMCI1A  -  Current  time  count  for  channel  A. 

TiMCHB  -  Current  time  count  for  channel  b. 

Procedures 

D£T$ADDR  -  Determine  the  destination  of  the  packet  from  the  attached 
hoc  t . 

D>}$  DECODES  EXCEPTION  -  External  ISLS  call  to  decode  error  exceptions. 

DISCLOSE  -  External  ISIS  call  to  close  an  1/0  handle. 

DQSDETACii  -  External  ISIS  call  to  detach  an  1/0  device. 

DQ$  EX  IT  -  External  ISIS  call  to  exit  the  current  program  back  to  the 
ISIS  operating  system. 

DQS ATTACH  -  External  ISIS  call  to  attach  an  I/O  device. 

DOS CREATE  -  External  ISIS  call  to  obtain  an  I/O  handle. 

DQIOPEN  -  External  ISLS  call  to  open  a  file. 

DOiKEAD  -  External  ISIS  call  to  read  an  opened  file. 

DOSWRITE  -  External  (SIS  call  to  write  an  opened  file. 

fwlT  -  initializes  the  variables  to  their  initial  states. 

INir$TAB  -  Initializes  the  network  and  data  link  layer  tables  and 
pointers  to  their  initial  values. 

LD$TAb$HSKP  -  liousokeep  a  specified  buffer  table  load  pointer. 

LOOP  -  Simulates  the  operation  of  another  UNID  in  the  network. 

R0UIE$1N  -  Route  received  packets  and  frames  from  the  network 
layer  and  the  network. 

ROD  l'E$0U  T  -  Send  the  frames  to  the  network  or  packets  to  the  network 


BUILD$I$PACtCET  -  Transforms  the  user  packet  into  a  frame  for  transfer 
to  the  network. 

S£kv'ICE$LOOP  -  Turns  a  frame  around  in  the  network.  The  source 
and  destination  headers  are  exchanged. 

SNJ3EQ  -  Takes  a  message  string  from  the  calling  procedure  and  outputs 
it  to  the  ISIS  operating  system. 

SkvC$TAB$HSKP  ~  Uousekeep  a  specified  buffer  table  service  pointer. 


Li uk  and  Locate  hatch  File 

CAUTION:  Do  not  change  address  or  other  parameters  in  the 
following  botch  tile.  They  are  nighly  hardware  dependent  on 
the  System  111  architecture  and  the  ISIS  operating  system. 


run  iinkHb  netnew.ubj,  small. lib 

run  locSb  netuew.Ink  ad( sm(code( 7300h) ,cons t(8b00h) ,da ta(9900h) ,  & 
stack(bdOOh) , memory (cdOOh) , ??seg(c200n) ) ) 


3.  SBC  544  Validation 


The  purpose  of  this  program  is  to  operate  the  network  layer 
software  on  the  Intel  SBC  544.  All  the  constants,  variables  and 
procedures  from  the  network  layer  siraulation  are  used  in  this  program 
with  the  following  exceptions: 

1.  The  READ,  WRITE,  EXIT  and  ERROR  ISIS  system  calls  are  not  used. 

2.  The  constants  R$CONN  and  W$CONN  are  not  used. 

3.  The  variables  ACTUAL,  BUFFER,  ERRNUM,  and  STATUS  are  not  used. 
The  following  constants,  variables  and  procedures  are  additions 

to  the  network  layer  simulation. 


Constants 

BRFO ,  BRF1 ,  BRF2 ,  BRF3  -  Data  rate  factor,  USART  0,  1,  2,  and  3. 

SlN$rfASR  -  Set  Interrupt  mask  mask. 

MASTER  -  Port  number  for  Master  Mode. 

SLAVE  --  Port  number  for  Slave  Mode. 

325 1A  USART  Constants: 

US$P0$CMD  -  SERIAL  PORT  0  COMMAND 
US4>P0$STAT  -  SERIAL  PORT  0  STATUS 
US$P0$DATA  -  SERIAL  PORT  0  DATA 
IJS$P1$CMD  -  SERIAL  PORT  i  COMMAND 
US$P1$STAT  -  SERIAL  PORT  1  STATUS 
US$P1$0ATA  -  SERIAL  PORT  1  DATA 
US$P2$CMD  -  SERIAL  PORT  2  COMMAND 
US$P2$STAT  -  SERIAL  PORT  2  STATUS 
US$P2$DATA  -  SERIAL  PORT  2  DATA 
US$P3$CMD  -  SERIAL  PORT  3  COMMAND 
US$P3$SIAT  -  SERIAL  PORT  3  STATUS 
US$P3$DA'L'A  -  SERIAL  PORT  3  DATA 
US$MUDE  -  SERIAL  PORT  MODE 
USICOMMAND  -  SERIAL  PORT  COMMAND 
US$RESET$CMD  -  RESET  USART 
US$DTR$ON  -  RTS , RX E , DTR , TX E 
US$CRT$CMD  -  RTS,ER,RXE,DTR,TXE 
IJS$Tn$CMD  -  R1'S,ER,RXE, TXK 
US$DTK$0FF  -  RTS,RXE,TXE 
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US$RXRDY  -  RECIEVER  READY 
US$TXE  -  TRANSMITTER  EMPTY 
US$TXRDY  -  TRANSMITTER  READY 
PARITY$MASK  -  MASK  OFF  PARITY  BIT 

3253  Interval  Timer  Constants: 

ITl$CONT  -  INTERVAL  TIMER  1  CONTROL 

IT1$CNTR0  -  COUNTER  0,  USART  0 

IT1$CNTR1  -  COUNTER  1,  USART  1 

ITUCNTR2  -  COUNTER  2,  USART  2 

IT2$CONT  -  INTERVAL  TIMER  2  CONTROL 

IT2$CNTR0  -  COUNTER  3,  USART  3 

IT2$CNTRI  -  COUNTER  4,  CNTR5  OR  SPLIT  CLOCKS 

IT2$CNTR2  -  COUNTER  5,  RST  7.5 

USART$CNTR$M3  -  DIVIDE  BY  N  RATE  GENERATOR,  MODE  3,  FOR  USART  CLK  * 

16,  CLK  =  1.2233  MHZ 
B19200  -  TIMER  VALUE  FOR  19.2  KBPS 
B9600  -  TIMER  VALUE  FOR  9600  BPS 

B48GO  -  TIMER  VALUE  FOR  4800  BPS 

B2400  -  TIMER  VALUE  FOR  2400  BPS 

B1200  -  TIMER  VALUE  FOR  1200  BPS 

BbOO  -  TIMER  VALUE  FOR  600  BPS 

B300  -  TIMER  VALUE  FOR  300  BPS 

B150  -  TIMER  VALUE  FOR  150  BPS 

Bi 10  -  TIMER  VALUE  FOR  110  BPS 

3155  Peripheral  Interface  Constants: 

P I $  PORTA  -  PORT  A  (OUTPUT) 

PI$PORTB  -  PORT  B  ( INPUT) 

PUPORTC  -  PORT  C  (INPUT) 

PI$STAT  -  PPI  STATUS 

PI$CMD  -  PPI  COMMAND 

PI$CNTR$LO  -  PPI  COUNTER  LO  BYTE 

PI$CNTR$UI  -  PPI  COUNTER  HI  BYTE 

PIICNTRILOCNT  -  PPI  COUNTER  TIME  CONST 

PI*CNfR$riICNT  -  PPI  COUNTER  TIME  CONST 

PI$INI I$CMD1  -  PPI  INITIALIZATION  COMMAND  1,  A  OUT,  B  &  C  IN,  STOP 
COUNT 

P1$INIT$CMD2  -  PPI  INITIALIZATION  COMMAND  2,  A  OUT,  B  6  C  IN,  START 
COUNT 

PI|INIT$US$INT1  -  USART  AND  I NT  CONT  RESET 
PI$INIT$US$INT2  -  USART  AND  I NT  CONT  NORMAL 
PI$PORTC$STAT  -  PORT  C  STATUS 
PI|PORTC$CTL  -  PORT  C  CONTROL 
PI$M2M1  -  A-MOOE  1,  B-MODE  2 
P I$OBF  -  OUTPUT  BUFFER  READY 
Pi$IBF  -  INPUT  BUFFER  READY 


8259  Interrupt  Controller  Constants: 


IC$ PORTA  -  PORT  A 
IC$P0RTB  -  PORT  B 

1C$ICW1  -  INIT  COMMAND  WORD  I,  (A7A6A5)  =  010;  EDGE  TRIG;  INTERVAL 
=  4;  SINGLE;  NO  ICW4 

IC$ICW2  -  INIT  COMMAND  WORD  2,  (A15-A0)  =  0 
IC$ ICW3  -  INIT  COMMAND  WORD  3,  NO  SLAVE  IN  IR 

INIT4MASK  -  '101010101T,  INITIAL  INTERRUPT  MASK,  OCW1;  RECEIVE  INTR 
ON,  TRANSMIT  INTR  OFF 

IC$EOI  -  END  OF  INTERRUPT  CMD,  OCW2,  ROTATE  (PRIORITY)  ON  NON¬ 
SPECIFIC  EOI 

IC$GCW3$SMMS  -  SPECIAL  MASK  MODE  SET 
IC$OCW3$SMMR  -  SPECIAL  MASK  MODE  RESET 


Variables 

BYTES»RECV$1,  BYTES$RECV*2,  BYTES$RECV$3,  BYTES$RECV$4  -  Integer  value 
Indicating  how  many  bytes  of  a  datagram  have  been  received  from  a 
host. 

BY  TES$SENI'$1,  BYTES$SENT$2,  BYTES$SENT$3,  BYTES$SENT$4  -  Integer  value 
Indicating  how  many  bytes  of  a  datagram  have  been  sent  to  the  host. 

CHAR$i,  CHAR$ 2,  CHAR$3,  CHAR$4  -  Place  holder  for  the  received  character 
In  the  receive  Interrupt  routine. 

RXTA$1 ,  RX'1'A$2,  RXTA$3,  RXTA$4  -  Boolean  flag  to  indicate  if  a  transmit 
acknowledge  has  been  received. 

RXTR$1 ,  RXTRI2,  RXTR$3,  RXTR$4  -  Boolean  flag  to  Indicate  if  a  transmit 
request  has  been  received. 

SEND$1,  SEND$2,  SEND$3,  SEND$4  -  Boolean  flag  to  indicate  when  a  host 
channel  Is  sending  data  to  Its  host. 

TA  -  Transmit  acknowledge  character. 

TR  -  Transmit  request  character. 

TRTAI1,  TRTAI2,  TttTA$3,  TRTA$4  -  boolean  flags  to  indicate  if  the 
transmit  request/transmit  acknowledge  handshake  is  in  use. 

l'XTA$l,  TXTA$2,  TXTA$3,  TXTA|4  -  Boolean  flag  to  Indicate  If  a  transmit 
acknowledge  was  sent. 

TXTR$1,  TXTR$2,  TXTR$3,  TXTR$4  -  Boolean  fi3g  to  indicate  If  a  transmit 
request  was  sent. 


Procedures 


INI  riALIZE$  BOARD  -  Initialize  the  hardware  integrated  circuits  on  the 
SBC  544. 

R$MASK  -  External  procedure  to  read  the  interrupt  mask  on  the  8085 
processor.  Linked  from  PLM80.LIB. 

S$riASK  -  External  procedure  to  set  the  interrupt  mask  on  the  8085 
processor.  Linked  from  PLM80.LIB. 


Li nk  and  Locate  Ba tch  File 

CAUTION:  Do  not  change  address  or  other  parameters  in  the 
following  batch  file.  They  are  highly  544  hardware  dependent 
on  the  SBC  544  architecture  and  the  network  layer  software. 

LINK  NEWLOC. OBJ ,PLM80.LIB  TO  NEWLOC. LNK  MAP 

LOCATE  NEWLOC.LNK  TO  NEWLOC  Si’ACKSIZE(  100H)  QRDER( CODE, DATA, & 
STACK, MEMORY)  CODE(60H)  DAfA(0A000H)& 

RESTART!)  MAP  PRINT( NEWLOC. MP2) 

TYPE  NEWLOC. MP2 

OBJ HEX  NEWLOC  TO  NEWLOC. HEX 


(• 


4.  Host  CP/M  Simulation 


The  purpose  of  this  program  Is  to  simulate  a  host  system  to  the  SBC 
544  network  layer  software.  All  the  constants,  variables  and  procedures 
from  the  network  layer  simulation  are  used  in  this  program  with  the 
exception  that  the  console  I/O  now  occurs  through  the  CP/M  system  calls 
and  the  actual  character  I/O  to  the  UNID  II  is  accomplished  through 
calls  to  an  assembly  language  module  linked  to  this  module. 

The  following  constants,  variables  and  procedures  are  additions  to 
the  network  layer  simulation. 

Constants 

ASCII(*)  -  Array  used  for  converting  hex  to  binary  and  binary  to  hex. 
BD0S2  -  BDOS  call  2-console  output. 

BD0S9  -  BDOS  call  9-print  string  until 

BDOS 10  -  BDOS  CALL  10-read  console  input  buffer. 

DATA$GRAM$SIZE  -  Number  of  bytes  from  host. 

DATA$TABLE$SIZE  -  Number  of  bytes  in  datagram  table. 

MAX$C0UNTRY$C0D£  -  Indicat-.s  country  codes  in  use. 

MAX$NETWORK$CODE  -  Indicates  UNIDs  operational  in  the  network. 
MAX$RXTA$TRIES  -  Maximum  number  of  TA  wait  tries. 

PACKET$TABLE$SIZE  -  Number  of  bytes  in  packet  table. 

TCP$DATA$SIZE  -  TCP  data  size. 

THIS$COUNTRY$CODE  -  Country  code  where  this  UNID  resides. 

THIS$UNID$NBR  -  Unique  address  for  this  UNID  in  its  country  code. 

Variables 

RESULT  -  Error  value  returned  by  BDOS  function  calls. 


BUFFER(128)  -  Line  buffer  used  for  console  input. 

CHAN$NLJM  -  Channel  number  in  which  to  load  the  test  datagrams. 
DEST$NET$CODE  -  Destination  network  code  for  the  test  datagrams. 
DEST$HOST$CODE  -  Destination  host  code  for  the  test  datagrams. 

CHAN$PTR  -  Pointer  to  the  current  datagram. 

RXTA$TRIES  -  Number  of  received  transmit  acknowledge  attempts. 

TRANS$1$RDY  -  Indicator  when  the  transmit  software  is  ready  to  transmit 
a  datagram. 

RX01NE  -  Pointer  to  next  available  space  to  receive  a  datagram. 

RX01NS  -  Pointer  to  next  datagram  to  service. 

RX01SZ  -  Size  of  receive  datagram  buffer. 

RX01TB  -  Receive  buffer  for  datagrams. 

IX01NE  -  Pointer  to  next  available  space  to  send  a  datagram. 
rXOlNS  -  Pointer  to  next  datagram  to  service 
TX01SZ  -  Size  of  receive  datagram  buffer. 

TX01TB  -  Transmit  buffer  for  datagrams. 

DESTINATION  -  Destination  of  the  datagram  for  program  control. 

DESTINATION$ADDRESS  -  Destination  address  of  datagram  from  IP  header. 

SOURCE$ADDRESS  -  Source  address  of  datagram  from  IP  header. 

BYTES$RECV  -  Integer  value  indicating  how  many  bytes  of  a  datagram  have 
been  received  from  a  host. 

BYTES$SENT  -  Integer  value  indicating  how  many  bytes  of  a  datagram  have 
been  sent  to  the  host. 

CHAR  -  Place  holder  for  the  received  character  in  the  receive  interrupt 
routine. 

RXTA  -  Boolean  flag  to  indicate  if  a  transmit  acknowledge  has  been 
received. 

RXTR  -  Boolean  flag  to  indicate  if  a  transmit  request  has  been  received. 

SEND  -  Boolean  flag  to  indicate  when  a  host  channel  is  sending  data  to 
its  hos  t. 


TA  -  Transmit  acknowledge  character. 

TR  -  Transmit  request  character. 

TRTA  -  Boolean  flags  to  indicate  if  the  transmit  request/ transmit 
acknowledge  handshake  is  in  use. 

TXTA  -  Boolean  flag  to  indicate  if  a  transmit  acknowledge  was  sent. 

TXTR  -  Boolean  flag  to  indicate  if  a  transmit  request  was  sent. 

Procedures 

BDOS  -  External  call  to  the  CP/M  operating  system  to  perform  a  BOOS 
call . 

CHK$RXTA  -  Procedure  to  check  the  receive  USART  for  a  received  transmit 
acknowledge  character. 

CHK$RXTR  -  Procedure  to  check  the  receive  USART  for  a  received  transmit 
request  character. 

EXIT  -  External  call  to  return  to  the  CP/M  operating  system. 

INIT  -  Procedure  to  initialize  the  variables  used  in  the  program. 

LD$TAB$HSKP  -  Procedure  to  adjust  the  pointers  to  the  next  available 
datagram  position  in  a  buffer  table. 

LOAD  -  Procedure  to  interactively  load  datagrams  into  a  buffer  for 
transmission  to  the  UNID. 

L00P2  -  Procedure  to  send  and  receive  a  datagram. 

RCV$1  -  Procedure  to  read  a  datagram  from  the  USART. 

READ  -  Procedure  to  read  a  line  of  buffered  input  from  the  host  console. 

READ$LINE  -  Procedure  to  interactively  read  and  interpret  a  line  of  text 
at  the  host  console. 

READ$RXTAB  -  Procedure  to  read  and  display  the  contents  of  the  receive 
buffer  table. 

READ$TXTAB  -  Procedure  to  read  and  display  the  contents  of  the  transmit 
buffer  table. 

SCLRCM  -  External  call  to  clear  the  USART  receive  port. 

SCMCHK  -  External  call  to  check  the  USART  receive  port  for  a  character. 

SCMIN  -  External  call  to  get  a  character  from  the  USART. 


SCMOUT  -  External  call  to  send  a  character  to  the  USART. 

SINIT  -  External  call  to  Initialize  the  host  CP/M  USART  port. 

SHDSEQ  -  Procedure  to  send  a  message  to  the  host  console  for  display. 

SRVC$TAB$HSKP  -  Procedure  to  adjust  the  pointers  to  the  next  to  service 
datagram  in  the  buffer  tables. 

TRANS$1  -  Procedure  to  send  a  datagram  to  the  USART. 


Link  and  Locate  Batch  File 

CAUTION:  Do  not  change  address  or  other  parameters  in  the 
following  batch  file.  They  are  highly  CP/M  system  dependent. 

LINK  CPMTMP.OBJ ,SBS.OBJ ,PLM80.LIB  TO  CPMTMP.LNK  MAP 
LOCATE  CPMTMP.LNK  TO  CPMTMP  STACKSIZE( 100d)  ORDER (CODE, DATA, & 
STACK, MEMORY)  CODE(103H)  MAP  PRINT ( CPMTMP. MP 2) 

TYPE  CPMTMP. MP2 

OBJHEX  CPMTMP  TO  CPMTMP. HEX 
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